Most WordPress sites installed before 2015 run on a latin1 character set. That was fine until emoji, non-Latin scripts, and special characters became standard in content. The fix is converting to utf8mb4, the MySQL character set that supports the full Unicode range. But the migration isn’t one-click safe, and operators who skip the collation audit often find mangled text in old posts weeks later.
Why utf8mb4 matters now
WordPress has shipped with utf8mb4 as the default character set since version 4.2 in 2015. If your database predates that, or if your host used an older MySQL template during setup, you’re likely still on latin1 or the older three-byte utf8 encoding.
The three-byte utf8 can’t store emoji, many Asian characters, or mathematical symbols. If a reader pastes an emoji into a comment form or you copy-paste content from a doc that includes a smart quote outside the latin1 range, MySQL either rejects the insert or converts the character to a question mark.
utf8mb4 uses four bytes per character and covers the entire Unicode standard. That means emoji, CJK ideographs, and symbols render correctly and survive round-trip edits in the WordPress editor.
The collation mismatch that breaks content
Character set defines which characters MySQL can store. Collation defines how MySQL compares and sorts them. When you convert a database from latin1 to utf8mb4, you also change the collation—typically from latin1_swedish_ci to utf8mb4_unicode_ci or utf8mb4_general_ci.
If your existing content contains extended ASCII characters—curly quotes, em dashes, accented letters—and those were stored as latin1 bytes, a straight conversion can misinterpret them. MySQL reads the old byte sequence as if it were already utf8mb4, producing garbled output: “don’t” instead of “don’t.”
This happens because the byte 0x92 in latin1 (right single quotation mark) has a different meaning in utf8mb4. The conversion tool changes the schema but doesn’t transcode the data unless explicitly told to.
How to convert without breaking old posts
The WordPress database charset converter in wp-admin → Tools → Database (added in WP 4.2) handles most cases, but it only appears if WordPress detects a charset mismatch. If the tool doesn’t show, your database and wp-config.php already match, or your host disabled the feature.
For manual conversion, use the WP-CLI command:
wp db convert-charset utf8mb4
This command checks each table, converts the schema, and attempts to recode existing data. But it can’t fix data that was already double-encoded or incorrectly inserted under the old charset.
Before you run any conversion:
- Export a full database backup via phpMyAdmin or your host’s backup tool.
- Check your MySQL version. utf8mb4 requires MySQL 5.5.3 or later; most hosts are on 8.0+ now, but confirm.
- Run a test query to identify problem rows:
SELECT post_title, post_content FROM wp_posts WHERE post_content LIKE '%â€%' LIMIT 20;
If you see garbled characters, your data is already mis-encoded and needs a two-step fix.
If you find corrupted rows, you’ll need to convert from the actual source encoding. Many databases labeled latin1 were silently storing utf8 bytes. In that case, convert from utf8 to utf8mb4, not latin1 to utf8mb4. Tools like mysqldump with the --default-character-set flag let you specify the real source encoding.
What breaks after conversion
Index length limits are the most common post-conversion issue. utf8mb4 uses four bytes per character, so a VARCHAR(255) index that worked under latin1 (255 bytes) now requires 1,020 bytes (255 × 4). MySQL’s default InnoDB index prefix limit is 767 bytes on older configurations.
If you hit this during conversion, you’ll see:
ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
The fix: enable innodb_large_prefix and set innodb_file_format=Barracuda in your MySQL config, or shorten the indexed column. Most modern managed WordPress hosts (including BigScoots) run MySQL 5.7+ with large prefixes enabled by default, but check if you manage your own VPS.
Plugins that write custom tables may also need updates. If a plugin creates a table after your conversion, it might default to the old charset unless the plugin explicitly sets utf8mb4 in its schema. Check any membership, LMS, or e-commerce plugins with custom tables.
When to skip the conversion
If your site is English-only, has no user-generated content, and you never use emoji or special characters, the conversion won’t break anything—but it also won’t deliver visible value. The character set becomes important when:
- You accept comments, forum posts, or form submissions from readers
- You publish multilingual content or quote non-English sources
- You paste from Google Docs, Notion, or other tools that insert smart quotes and em dashes
- You use emoji in headlines, CTAs, or social-share snippets
For solo operators running a single-language blog with no UGC, the status quo works. But if you plan to scale, open comments, or accept guest posts, convert now before you have 500 posts to audit.
One last thing: After conversion, update your wp-config.php to match. Set:
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
Without that, WordPress will keep writing new content in the old charset, and you’ll be back where you started.
Hit a wall with WordPress hosting performance or database issues? Subscribe to One Two Three Send for operator-focused breakdowns every week—no fluff, just the technical details that matter.