Serialized Data Fixer

WordPress keeps arrays and objects in the database as PHP serialize() output, a format that writes the byte length in front of every string — s:5:"hello". Run a plain SQL REPLACE() across the tables and the text changes while those numbers stay as they were, so unserialize() refuses the value and the row reads back as empty. That is why widgets disappear, menus empty out and theme settings return to their defaults after a domain change, even though the data is still sitting in the table exactly where you left it.

Serialized Data Fixer parses the value with those declared lengths treated as hints rather than facts. It works out where each string really ends by looking for a terminator that leaves valid data behind it, then writes the correct UTF-8 byte length back — bytes, not characters, which is what PHP counts and what catches people out on accented titles and emoji. Array and object element counts are recounted the same way, so a list that gained or lost an entry declares the right number again. Floats keep their exact printed text, reference markers are copied through untouched, and running the tool on a value that was already sound returns it unchanged and says so.

There are two outputs. Repaired serialized data is what you paste back into option_value or meta_value; readable JSON is there when you only want to see what a plugin has actually stored. The optional find and replace rewrites string values inside the parsed structure and recomputes the byte count of every string it touches, so a flat option survives a domain or upload-path swap that a SQL REPLACE() would have wrecked — with one exception, set out below, for a string that is itself serialized data. If the text came out of a mysqldump with escaped quotes and backslashes, tick the SQL dump box before running. Everything happens in this browser tab: database contents are not uploaded, and the page works with the network off.

The limits matter more than the feature list. One value per run — anything after the end of the first value is refused, so a dump or a column of rows has to be done a row at a time. Only the standard markers are understood: s, a, O, i, d, b, N and references. A class that implements Serializable (C:) or a backed enum (E:) is reported as an unrecognised value rather than repaired. Find and replace touches string values only, never array keys or class names. The JSON view is one-way — objects gain a __class__ key and references become placeholder text, so it reads well but cannot be pasted back. And where a string genuinely contains the terminator sequence, the end is chosen by scanning forward for a quote-and-semicolon whose next few characters begin like another marker, preferring the candidate whose byte count matches the declared length and otherwise taking the earliest one — a heuristic that can pick wrong.

Double serialization is the limit to check before you trust an output. Plugins and postmeta rows routinely keep one serialize() result inside another as a string, and every string here is treated as opaque text, so the nested layer is never entered. If that inner data holds a string of its own, a broken value cannot be repaired at all: the first terminator inside the nesting is taken for the end of the outer string and the run stops with a position complaint. On a nested value that is still sound, find and replace produces the very fault this page is about — the outer length is rewritten correctly while the inner s: counts keep their old totals — and running the tool again on that output reports that nothing was broken, because it cannot see inside a string. For anything nested, unserialize it in PHP or let WP-CLI search-replace walk the levels.

Runs on your device. Your file is processed directly in this browser.