>_ tools --serialize

PHP Serialize / Unserialize for WordPress

Paste a PHP-serialized string → clean tree → re-serialize with corrected byte-lengths after search/replace. For WordPress wp_options, wp_postmeta, widgets & theme-mods. Everything runs in your browser; nothing is uploaded.

SERIALIZED

FIND → REPLACE

TREE VIEW

RE-SERIALIZED

How to use: Paste a raw PHP-serialized string (from wp_options etc), hit Parse. If a value looks broken, fill find → replace and hit Re-serialize - it rewrites every s:<len>: prefix from the real byte length, so unserialize() will not error. Or use Simple length-fix to just repair a damaged blob.
Debug Log Analyzer Paste a debug.log and see what actually failed. wp-config Generator The file many of these options live in. JSON Formatter Same tree view for JSON payloads. SQLite ⇄ MySQL Converter Migrating data, not just options.

>_ FAQ

Why does a serialized WordPress option break after a search/replace?

PHP-serialized strings store the byte length of each string as a prefix (s:<len>:"..."). A search/replace or migration that changes a value without updating that length makes PHP unserialize() throw "Error at offset." This tool parses the string, shows the mismatch, and re-serializes with every length recalculated from the real UTF-8 byte length.

Is the serialized length measured in characters or bytes?

PHP strlen counts UTF-8 bytes, not characters. This tool is byte-accurate, so emoji, accented letters, and CJK text are handled correctly - the most common cause of the "shown length" mismatch.

Is my data uploaded anywhere?

No - the parser and re-serializer run entirely in your browser with JavaScript. Nothing is uploaded, logged, or stored; close the tab and it is gone.

byte lengths use the PHP strlen convention (UTF-8 bytes) · test the result with unserialize() in PHP · no server, nothing is uploaded