This error means MySQL received text it cannot store in that column's character set. The bytes shown in the message, such as \xF0\x9F\x98\x80, are the UTF-8 encoding of the character it rejected. A four-byte sequence starting with \xF0 is almost always an emoji or a rare character, and the column is using the 3-byte utf8 charset that cannot hold it.
ERROR 1366 (HY000): Incorrect string value: '\xF0\x9F\x98\x80' for column 'name' at row 1
Why utf8 is not UTF-8
In MySQL, utf8 is an alias for utf8mb3, which stores at most three bytes per character. Real UTF-8 needs up to four, and MySQL's name for that is utf8mb4. Emoji, some CJK extension characters and many symbols fall outside the three-byte range. MySQL 8.0 still treats utf8 as an alias of utf8mb3 but warns that it is deprecated; use utf8mb4 explicitly.
Step 1: check where the mismatch is
Several layers must agree: the column, the table, the database, the connection and the server defaults.
SHOW CREATE TABLE users\G
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
Look at the column definition (CHARACTER SET utf8mb3) and the connection variables (character_set_client, character_set_connection, character_set_results). If the connection says latin1 or utf8mb3, even a utf8mb4 column will reject or mangle four-byte data.
Step 2: convert the schema
For one table:
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
For the database default (affects new tables only):
ALTER DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Take a backup first. Converting rewrites the table and can take a long time and lock writes on large tables, and index sizes grow because each character may reserve four bytes. utf8mb4_unicode_ci is portable between MySQL and MariaDB; MySQL 8.0 also offers utf8mb4_0900_ai_ci, which MariaDB lacks.
Step 3: fix the connection
Tell the server what your client sends:
SET NAMES utf8mb4;
Better to set it in the driver or framework config so it applies on every connection:
- PDO:
mysql:host=127.0.0.1;dbname=shop;charset=utf8mb4 - Laravel
config/database.php:'charset' => 'utf8mb4', 'collation' => 'utf8mb4_unicode_ci' - Django: the MySQL backend uses
utf8mb4by default in current versions; set'OPTIONS': {'charset': 'utf8mb4'}to be explicit. - WordPress:
define('DB_CHARSET', 'utf8mb4');inwp-config.php. - mysqldump and the client:
--default-character-set=utf8mb4.
Also set server defaults in my.cnf:
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
[client]
default-character-set = utf8mb4
Restart MySQL for server defaults to apply. Existing tables keep their own charset until altered.
Step 4: index length limits
When converting, you may see "Specified key was too long; max key length is 767 bytes" (error 1071). With utf8mb4, a VARCHAR(255) index needs 1020 bytes. Modern InnoDB (MySQL 5.7+ and 8.0, with DYNAMIC row format) allows 3072-byte keys, so this mostly affects old servers or tables still on COMPACT format. Fix with ROW_FORMAT=DYNAMIC, a shorter column such as VARCHAR(191) on old servers, or a prefix index.
Step 5: check your data pipeline
If the error comes from imports or API data, validate what you are sending:
- Files saved as Latin-1 or Windows-1252 but declared as UTF-8 give invalid bytes like
\xE9or\x92in the message. Convert withiconv -f WINDOWS-1252 -t UTF-8 in.csv > out.csv, or load with the correctCHARACTER SETclause inLOAD DATA. - Double-encoding produces garbled sequences, such as an accented letter turning into two unrelated characters. Fix the connection and re-import; do not convert the column a second time.
- If the message shows an
\x00or binary garbage, you may be inserting a binary blob into a text column. UseBLOBorVARBINARY.
Not the same error
ERROR 1366: Incorrect integer value: '' for column 'qty' at row 1 shares the number but is a type problem: the strict sql_mode rejects an empty string for a numeric column. Send NULL or a number, and validate input in the application. Decimal and date columns produce similar 1366 or 1292 messages.
Next steps
- Inspect encodings with the URL Encoder/Decoder and the Base64 Encoder/Decoder.
- Problems at statement level? See MySQL error 1064.
- Foreign keys failing after conversion? Read MySQL error 1215.
- Check page headers for the declared charset with the HTTP Header Checker.
FAQ
Why does it fail only with emoji?
Emoji need four bytes in UTF-8, and utf8mb3 stores up to three. Converting to utf8mb4 fixes this.
Do I need to change the collation too?
Yes, convert both together. Mixed collations cause errors in comparisons and foreign keys.
Will converting to utf8mb4 break existing data?
Valid three-byte text converts losslessly. Already-corrupted text (double-encoded) stays corrupted, so test on a copy first.
Is utf8mb4 slower?
Storage and index size grow somewhat, but for most sites the difference is not noticeable compared with the cost of broken input.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.