What this tool does
WordPress stores non-scalar options — arrays and objects — in the wp_options table as PHP serialize() strings. If you edit an option_value directly in the database, it must be valid serialized data or WordPress fails to unserialize() it and the setting silently breaks. This tool builds correct serialized strings and decodes existing ones.
Serialize
Plain string
Serializes the whole input as one string: s:LEN:"…";. Newlines and Unicode are counted as UTF-8 bytes.
JSON → PHP
Paste JSON and get a PHP-serialized array. Objects become associative arrays, arrays become lists, and integer-like keys are cast to PHP integer keys.
Multiline / bulk
One value per line, each serialized separately.
Deserialize
Paste an existing serialized string from wp_options and get readable JSON back, with the detected top-level type. Read a value before you change it, or check that a blob is valid.
Examples
active_plugins — a list of plugin files
a:2:{i:0;s:19:"akismet/akismet.php";i:1;s:27:"woocommerce/woocommerce.php";}
Paste into Deserialize to read it as ["akismet/akismet.php","woocommerce/woocommerce.php"]. To add a plugin, edit the JSON and re-serialize with JSON → PHP.
A settings array — associative keys
a:2:{s:8:"logo_url";s:28:"https://example.com/logo.png";s:5:"width";i:200;}
Source JSON: {"logo_url":"https://example.com/logo.png","width":200}.
A scalar option is NOT serialized
Single strings and numbers — like siteurl or blogname — are stored raw. Only arrays and objects get serialized. When in doubt, deserialize the existing value first to see what WordPress expects. If a search-replace left a serialized value with wrong lengths, use Fix Serialized Data.
Why byte length, not character count?
PHP prefixes each serialized string with its length in bytes. A character like é is two bytes in UTF-8, and emoji are four. Counting characters instead of bytes is the single most common reason a hand-edited option won't unserialize.