The database character set determines which characters can be stored in your tables and how they're encoded. Get it wrong and you'll see “?” marks where emojis should be, or mangled accented characters. Get it right and everything just works.
Recommended: utf8mb4
utf8mb4 is the modern correct choice — it supports the full unicode range including emojis (😀, 🎉), uncommon CJK characters, mathematical symbols and ancient scripts. New installations default to utf8mb4 throughout.
Why Not Just utf8
MySQL's utf8 historically supported only 3-byte unicode characters (Basic Multilingual Plane). Emojis live in the supplementary planes and require 4 bytes. Storing an emoji in a utf8 column either truncates the data or throws an error.
Where the Character Set Matters
- Table definitions (per-table
DEFAULT CHARSET). - Column definitions (per-column override).
- Connection charset (set on each new connection).
- Database default (used when CREATE TABLE doesn't specify).
- HTML page meta tag (
<meta charset="UTF-8">). - HTTP response Content-Type charset.
Migrating from utf8 to utf8mb4
- Backup the database. This is reversible but important to insure against errors.
- Set the global default to utf8mb4.
- Convert each table:
ALTER TABLE x CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci. - Restart the application so new connections use utf8mb4.
- Test with an emoji-containing record.
Worked Examples
- Consumer-facing app: utf8mb4 throughout — users use emojis everywhere.
- B2B legacy system: utf8 sufficed for years; migrating now because a customer's company name includes a special character utf8 can't store.
- International SaaS: utf8mb4 essential to support all locales.
- Highly-restricted legacy: latin1 — only viable if all input is guaranteed to be Western European; emoji submission throws an error.