Error fix · Developer errors

MySQL ERROR 1366: Incorrect String Value for Column (utf8mb4 Fix)

Fix MySQL ERROR 1366 Incorrect string value for emoji and 4-byte characters. Convert to utf8mb4, set the connection charset, and avoid index length traps.

Error messageERROR 1366 (HY000): Incorrect string value: '\xF0\x9F\x98\x80' for column 'name' at row 1

By SiteDownCheck Editorial · Updated November 4, 2026 · 4 min read

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 utf8mb4 by default in current versions; set 'OPTIONS': {'charset': 'utf8mb4'} to be explicit.
  • WordPress: define('DB_CHARSET', 'utf8mb4'); in wp-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 \xE9 or \x92 in the message. Convert with iconv -f WINDOWS-1252 -t UTF-8 in.csv > out.csv, or load with the correct CHARACTER SET clause in LOAD 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 \x00 or binary garbage, you may be inserting a binary blob into a text column. Use BLOB or VARBINARY.

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

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.