The error appears when a JSON function receives character data that is not encoded in utf8 or utf8mb4.
MySQL error 3145 ER_INVALID_JSON_CHARSET_IN_FUNCTION occurs when a JSON function gets non-UTF8 text. Convert the input string or column to utf8mb4, or cast it with CAST(col AS CHAR CHARACTER SET utf8mb4), then rerun the query to resolve the issue.
ER_INVALID_JSON_CHARSET_IN_FUNCTION
Error 3145 fires when any MySQL JSON function, such as JSON_OBJECT or JSON_EXTRACT, processes a string that is not encoded in utf8 or utf8mb4. MySQL enforces UTF8 family encodings for JSON data because the internal JSON binary format assumes Unicode.
The server halts the statement, returns SQL state 22032, and shows the message "Invalid JSON character data provided to function ...; utf8 is required." This validation first appeared in MySQL 5.7.8.
The most common trigger is passing a column defined with latin1, cp1252, or another legacy charset into a JSON_ function without converting it. Even a single varchar literal in a different charset can cause the exception.
The error also appears when CONCAT, GROUP_CONCAT, or stored procedure variables assemble mixed-charset strings that ultimately feed a JSON function. The last evaluated character set governs the entire expression.
Convert every argument to utf8mb4 before the JSON call. Use CAST( ... AS CHAR CHARACTER SET utf8mb4) or the CONVERT(expr USING utf8mb4) function. For columns, consider permanently altering them to utf8mb4 to avoid repeated conversions.
If the source data must remain in another charset, wrap only the JSON-bound expression in a conversion: JSON_OBJECT('name', CONVERT(name USING utf8mb4)).
Legacy tables created in latin1 often break new JSON code added during migrations. Bulk ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 fixes the root cause and simplifies future development.
APIs that accept client-side text sometimes insert values tagged as utf8 but actually encoded differently. Enforce connection collation utf8mb4 and enable strict SQL modes to reject bad input early.
Create all new schemas, tables, and connections with default_character_set=utf8mb4 and default_collation=utf8mb4_0900_ai_ci. This eliminates charset mismatches for JSON work.
Validate incoming text at the application layer and log any conversion warnings. Galaxy users can run automated lint rules that flag non-UTF8 columns referenced by JSON functions, catching issues before they reach production.
Error 3144 ER_INVALID_JSON_TEXT reports malformed JSON rather than charset issues. Error 3146 ER_INVALID_JSON_PATH_CHARACTER_SET arises when paths, not values, use the wrong charset. The fixes are similar: ensure utf8mb4 encoding.
Varchar or text columns defined in latin1 feed JSON_OBJECT without conversion.
CONCAT of utf8mb4 and latin1 expressions adopts the first argument charset, causing hidden issues.
Applications connecting with character_set_client=latin1 insert data that later breaks JSON queries.
Triggers on malformed JSON syntax rather than charset.
Raised when a JSON path string is not utf8.
Indicates illegal wildcard characters in the JSON path expression.
No. MySQL hard-enforces UTF8 for JSON to guarantee correct binary storage. Workarounds require converting the data.
utf8mb4 is recommended because MySQL's utf8 encoding is limited to three-byte Unicode. Both pass the charset check, but utf8mb4 supports full Unicode.
Inline CAST adds minimal overhead on small strings. Converting the column at rest avoids repeated per-row conversions and usually performs better overall.
Galaxy highlights charset mismatches in the editor and suggests ALTER statements or CAST wrappers via its AI copilot, preventing runtime errors.
.avif)
.avif){kind=logo}
