What is utf8mb4 and why does it matter?

utf8mb4 is a MySQL character set that stores the full range of Unicode, including emoji and some less common characters from languages like Chinese and Japanese, while MySQL's older setting simply named "utf8" only covers a smaller three-byte subset of it. The naming is confusing and it is a genuine historical mistake rather than a deliberate design choice, but the practical difference matters for any database storing modern, unfiltered text.

How MySQL ended up with two "utf8" settings

Real UTF-8 encodes characters using between one and four bytes each, depending on the character. When MySQL implemented the character set it called "utf8" many years ago, it only supported up to three bytes per character, which covers the vast majority of everyday text but leaves out an entire range of characters that need the full four bytes, including every standard emoji and a number of rarer characters used in some Asian languages. Renaming or fixing the original "utf8" later would have broken every database already using it, so MySQL instead added a genuinely complete implementation under a new name, utf8mb4, meaning UTF-8 with a maximum of 4 bytes per character. The confusing part is that MySQL's "utf8" was never actually complete UTF-8 to begin with, despite the name.

What actually goes wrong with the older setting

A database or column still set to MySQL's "utf8" will reject or silently mangle any character that needs four bytes to store. In practice this shows up as emoji disappearing, turning into question marks, or in some cases causing the entire insert to fail outright depending on how strictly the connection is configured. It is rarely obvious during development, where test data does not usually include emoji, and then shows up in production the first time a real user pastes one into a comment, a name field, or a message.

Why it matters more today than it used to

Emoji are now a normal part of everyday text, appearing in names, comments, product reviews, chat messages and social content across almost every kind of website. A database that cannot store them cleanly is going to encounter the problem eventually on any site that accepts free-text input from real users, not as an edge case but as routine input.

What to actually do about it

Modern software, including current versions of WordPress, defaults to utf8mb4 on a fresh install, so this often needs no action at all on a new site. It becomes relevant when working with an older database that was created under MySQL's original "utf8" setting, which was the long-standing default for many years before utf8mb4 became standard. Changing a database character set or collation covers exactly how to convert an existing database and its tables over to utf8mb4 safely, including the backup you should take first.

Which collation to pair it with

The character set and the collation are separate settings, and utf8mb4 should be paired with a matching collation such as utf8mb4_unicode_ci, which is the sensible default for most sites because it sorts and compares text using rules that match how people actually expect alphabetical ordering to behave. This is covered in more detail, along with the exact statements to run, in the guide linked above.

If you are setting up a new database from scratch, choosing utf8mb4 with utf8mb4_unicode_ci from the start avoids ever needing to convert anything later — see creating a MySQL database and user for where that choice fits into the setup.