You're Not Broken – phpMyAdmin Is Being Overly Cautious
I get it. You've got a table with a BINARY or VARBINARY column storing something like a short hash or a token, and phpMyAdmin shows it as 0x48656C6C6F instead of the actual value. Feels like the tool is fighting you. It is. But the fix is one line in a config file.
The Fix: Set $cfg['DisplayBinaryAsHex'] to false
Open /etc/phpmyadmin/config.inc.php (or wherever your phpMyAdmin config lives – check your distro. On Ubuntu it's /etc/phpmyadmin/config.inc.php, on Windows it's C:\xampp\phpMyAdmin\config.inc.php). Add this line near the bottom, before any closing ?>:
$cfg['DisplayBinaryAsHex'] = false;Save the file, reload phpMyAdmin, and refresh your table. Your binary column now shows the actual bytes as a string. If it's a BLOB column, same deal – it'll stop showing hex and show raw data. If phpMyAdmin complains about rendering a long blob in the table view, switch to the “Browse” tab and click the row – it'll display fine.
Real-world example: Had a client last month storing OAuth tokens in a VARBINARY(255) column. Every time they looked at the table, the token was a giant hex string. They'd copy it, convert it online, paste it back – took 15 minutes per check. One tweak and they saw the token plain text. Saved them an hour a week.
Why Does This Happen?
phpMyAdmin's developers set DisplayBinaryAsHex to true by default because binary data can contain non-printable characters that break HTML rendering. Think of a BINARY(16) UUID stored as raw bytes – it'll show up as garbage characters if printed as-is. So they default to hex to keep things safe. Problem is, it assumes all binary data is unreadable. When you're storing short text in a binary column (like a token, a short hash, or an encoded ID), it's just text – showing hex is overkill and annoying.
Other Variations of This Issue
1. Only some columns show hex – check data types
If only BLOB columns show hex but VARBINARY doesn't, double-check your column type. BLOB is for binary large objects – even with DisplayBinaryAsHex = false, phpMyAdmin might still hexify a BLOB if it's over 10KB. For small blobs (under 1KB), it works fine. For large ones, you'll need to scroll to see the raw value. Real advice: if you're storing short text, use VARBINARY(n) instead of BLOB – it's cleaner and phpMyAdmin handles it better.
2. The setting doesn't stick after updates
phpMyAdmin updates sometimes overwrite config.inc.php. I've seen that happen on Debian and CentOS. Keep a backup snippet ready. Better yet, put the setting in a separate include file that gets loaded after the main config. Add this to config.inc.php:
include('/etc/phpmyadmin/override.php');Then create /etc/phpmyadmin/override.php with the $cfg['DisplayBinaryAsHex'] = false; line. Now updates won't touch it.
3. Still seeing hex in the structure view
The setting only affects the browse/query results. In the table structure view, phpMyAdmin still shows a column's default value as hex. That's not fixable via config – it's hardcoded. Workaround: use the SQL tab and run SELECT * FROM your_table to see real values.
How to Prevent This From Breaking Things
If you're designing a new table and plan to store short text that happens to be binary (like a hash, token, or encoded key), use VARCHAR instead of BINARY or VARBINARY. MySQL handles it the same way performance-wise for short strings, and phpMyAdmin never messes with it. But if you're locked into binary columns – and sometimes the schema won't change – the config fix above is permanent and painless.
One more thing: if you're on a shared host and can't edit config.inc.php, talk to your host. Some allow per-user config overrides via ~/.phpmyadmin/config.inc.php. Not common, but worth asking. If they can't help, you're stuck using the SQL tab. Sorry, that's the reality of cheap hosting.