DB_COLLATE in WordPress: What It Is and How It Works
03.06.2026
The DB_COLLATE constant in WordPress is used to define the collation of your database tables. Collation determines how string comparison is performed in the database, including the sort order and case sensitivity.
For closely related WordPress database charset / encoding topics, see .htaccess UTF-8 default charset guide and AddDefaultCharset Apache guide.
What Is Collation in Databases?
- Collation is a set of rules that determines how strings are compared and sorted in a database.
- It works in combination with the character set (DB_CHARSET), which defines the encoding of text in the database.
Common Collations in MySQL
| Collation | Description |
|---|---|
| utf8_general_ci | Case-insensitive collation for UTF-8. |
| utf8_unicode_ci | Case-insensitive, better for multilingual data. |
| utf8mb4_general_ci | Case-insensitive collation for UTF-8 with full Unicode support (including emojis). |
| utf8mb4_unicode_ci | Case-insensitive, better accuracy for multilingual data with full Unicode support. |
| utf8_bin | Case-sensitive collation for UTF-8. |
The Role of DB_COLLATE in WordPress
The DB_COLLATE constant defines the collation for WordPress database tables. If left empty, the default collation of the MySQL server is used.
Location in wp-config.php
define('DB_COLLATE', '');
- Default value: An empty string ('') means WordPress will use the MySQL server default collation.
- Custom value: You can set a specific collation, like:
define('DB_COLLATE', 'utf8mb4_unicode_ci');
Why Set or Change DB_COLLATE?
- To Ensure Consistency:
- All tables in your database should ideally use the same collation to avoid errors like:
Illegal mix of collations - For Full Unicode Support:
- Use
utf8mb4_unicode_cito handle emojis and other special characters.
- Use
- Performance vs. Accuracy:
- _general_ci: Faster, but less accurate for multilingual sorting.
- _unicode_ci: More accurate for complex languages but slightly slower.
How to Check Your Current Collation
- In phpMyAdmin:
- Go to your database.
- Check the collation for each table under the "Collation" column.
- Using MySQL Command Line:
SELECT TABLE_NAME, TABLE_COLLATION
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'your_database_name';
How to Change Collation
Update the wp-config.php File
Change or add the DB_COLLATE constant:
define('DB_COLLATE', 'utf8mb4_unicode_ci');
Change Collation of Existing Tables
- Backup your database before making changes.
- Use a MySQL query to update collation for all tables:
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Replace wp_posts with the table name.
Use a Plugin
Plugins like Better Search Replace can help update collation for all tables.
Best Practices
- Use utf8mb4 for Modern WordPress Sites:
utf8mb4_unicode_ciis recommended for full Unicode support, including emojis.- Avoid
utf8, as it does not support the full range of Unicode characters.
- Ensure Compatibility:
- Make sure your MySQL version supports the chosen collation (e.g.,
utf8mb4requires MySQL 5.5.3 or later).
- Make sure your MySQL version supports the chosen collation (e.g.,
- Keep Collation Consistent:
- All tables and columns should use the same collation to prevent conflicts.
Example: Setting DB_COLLATE in wp-config.php
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
- DB_COLLATE determines how text data is compared and sorted in WordPress.
- Use utf8mb4_unicode_ci for modern WordPress installations.
- Update collation consistently across the database to avoid errors.
Yes for 99% of sites. Empty (`define('DB_COLLATE', '')`) tells WordPress "use the database's default" — and the modern default (`utf8mb4_unicode_ci` or `utf8mb4_0900_ai_ci`) is correct. Only set DB_COLLATE explicitly if you have a specific reason: legacy sites, multi-language sorting rules, or known MySQL/MariaDB version difference.
unicode_ci follows the Unicode standard for sorting (â sorts near a, ß sorts near s); general_ci is faster but sloppier (â and ß sort as their byte values). For multi-language content, unicode_ci is correct. general_ci is a relic from when CPU mattered more than correctness — avoid for new installs.
Possible. MariaDB 10.5 ships utf8mb4_uca1400_ai_ci as default — different collation than MySQL 5.7's utf8mb4_unicode_ci. If your dump pins specific collations and the target server doesn't have them, ALTER TABLE statements fail. Strip COLLATE clauses from the dump (`sed -i 's/COLLATE [a-z0-9_]*//g'`) and let the server choose, or convert tables after import with ALTER TABLE … CONVERT TO.
Probably not directly — the fix is DB_CHARSET. Set `DB_CHARSET = 'utf8mb4'` (not utf8) in wp-config.php. Then ensure tables are actually utf8mb4: `ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci`. DB_COLLATE only sets the sort order; the character set is what stores the bytes.
Cache-Control: max-age with no-store or no-cache
Understanding cpaddons in cPanel — What It Is & How to Manage It
Set Encoding for Dynamic Content with charset=windows-1251


