MySQL raises ER_INVALID_JSON_CHARSET when a JSON value is built from a string that is not encoded in UTF8, UTF16, or UTF32.
MySQL error ER_INVALID_JSON_CHARSET happens when you try to insert or build JSON from text stored in a non-Unicode character set like latin1. Convert the input or column to utf8mb4, then re-run the statement to clear the error.
ER_INVALID_JSON_CHARSET
Error 3144 is triggered when MySQL attempts to create or parse a JSON document from a string that is encoded with a character set other than UTF8, UTF16, or UTF32. The server refuses the operation to guarantee valid JSON storage.
The error appears during INSERT, UPDATE, SELECT JSON_ functions, or CAST operations if the input string, column, or literal uses a non-Unicode charset such as latin1, cp1252, or ascii while sql_mode allows strict JSON validation.
Leaving the issue unresolved blocks data writes, breaks API responses, and can hide downstream bugs. Correcting the charset ensures consistent JSON encoding, enables binary JSON storage efficiency, and prevents silent data corruption.
MySQL 5.7.8+ enforces that JSON text must be Unicode. Any attempt to feed non-Unicode bytes into JSON parsing raises ER_INVALID_JSON_CHARSET. Typical triggers include legacy tables created with latin1, improper client_encoding settings, or imported CSV files.
Fixes involve converting offending columns or literals to utf8mb4, altering table defaults, and ensuring the client session uses utf8mb4. Always back up data before altering character sets.
Applications that store JSON blobs in TEXT columns often fail after an upgrade to 5.7.8+. Bulk ETL jobs may load latin1 files, causing this error mid-transaction. Adjust the LOAD DATA statement or set character_set_connection.
Use utf8mb4 as the default schema charset, validate client encodings, and store JSON in native JSON columns defined as utf8mb4. Add test cases that confirm JSON functions run without charset errors.
Similar issues include 3140 (ER_INVALID_JSON_TEXT) for malformed JSON and 3143 (ER_INVALID_JSON_PATH_CHARSET) for path expressions. Converting data to utf8mb4 typically resolves these as well.
Columns defined as latin1, ascii, or other non-Unicode sets store the string, then MySQL rejects JSON conversion.
If character_set_client or character_set_connection is latin1, literals are treated as latin1 even if the bytes are UTF8.
LOAD DATA or ETL scripts may import latin1 files directly into JSON columns without explicit character set handling.
Calling JSON_EXTRACT on a non-JSON TEXT column forces an internal cast that fails when the data uses latin1.
Raised when the JSON text is syntactically invalid, not just wrongly encoded.
Occurs if the JSON path string is in a non-Unicode charset.
Triggered by wildcard misuse in JSON path expressions.
Run SHOW FULL COLUMNS FROM table_name to see Collation for each column.
No. MySQL always enforces Unicode for JSON values starting from 5.7.8.
Use utf8mb4 because utf8 in MySQL is limited to three bytes and does not cover all Unicode code points.
Galaxy's SQL editor highlights column charsets, suggests utf8mb4 conversions, and lets you run the ALTER TABLE commands directly with AI-generated patches.
.avif)
.avif){kind=logo}
