PHP Serialize / Unserialize

Features

• Three directions: unserialize, serialize and session data parsing
• Unserialize output as JSON or as a PHP array literal you can paste into code
• String lengths are read in bytes, so non-Latin text and emoji stay aligned
• PHP arrays become JSON arrays or objects depending on whether the keys run from 0, matching json_encode()
• Object properties are restored without letting the class name leak into the JSON, where it has no place
• Session data is split on the pipe; a value that cannot be read falls back to a string instead of failing the whole file
• A session file truncated on the final semicolon still reads
• Serialize direction also measures bytes, so non-Latin data round-trips through PHP unserialize()
• Trailing whitespace and stray semicolons are tolerated, since values lifted from a database or log often carry them
• Nesting deeper than 64 levels stops instead of blowing the call stack
• Everything runs locally in the browser; your data is never uploaded

How to use

1. Pick a direction
2. Paste the serialized string, the JSON or the session file contents
3. For unserialize, pick the output: JSON to work with, a PHP array literal to paste into code

FAQ

Why are string lengths in bytes and not characters?

Because that is what the PHP format specifies: the number after `s:` counts bytes. `s:2:"é"` is correct, since that letter takes two bytes but is one character — write `s:1:"é"` and PHP unserialize() fails too. Plenty of online converters count characters, which works on pure ASCII and then reports a format error the moment any multi-byte text appears. The reported position is nowhere near the cause, so it usually gets misdiagnosed as corrupted data.

Why does a PHP array sometimes become a JSON array and sometimes an object?

Because PHP has one array type serving as both list and dictionary, while JSON splits that into two. The rule here is: keys running 0, 1, 2… become a JSON array, anything else becomes an object — exactly what PHP own json_encode() does, so unserializing and re-encoding gives the same result as this tool. Keys like 1,2,3 or any string key produce an object, and numeric keys are written as strings, as JSON requires.

Where did the object class name go?

It does not appear in the JSON, because JSON has nowhere to put it — inventing a key like `__class` would fabricate data and make downstream code treat a field that never existed as real. The properties themselves are preserved in full; if you need the class name, use the PHP output or read the raw value. Note also that references (`R:` and `r:`) are deliberately unsupported: they mean "this entry is the same memory as an earlier one", and expanding them into two independent copies looks right while changing the meaning, so this tool reports an error instead.

Is it safe to paste the decoded data back into PHP unserialize()?

That depends on where the data came from. PHP unserialize() runs `__wakeup()` and `__destruct()` when it restores an object, which is how an attacker can hand you a payload that executes code — the classic PHP object injection. This tool only parses text into JSON and executes nothing, but if you take serialized data of unknown origin back into your own PHP code, the risk lives in that step. Cache entries and your own queue messages are fine; for anything user-submitted or forwarded by someone else, think about the source first.

Why is session data supported at all?

Because a PHP session file is not one serialized value — it is `name|value` entries concatenated, so it needs its own reader. This reads the default `php` serialize handler. If your project uses `php_binary` or `php_serialize` the shape differs, and values that cannot be read are kept as plain strings rather than failing the file, so you can at least see which keys exist.

Is my data uploaded?

No. Parsing and generation happen entirely in browser memory; the page makes no requests and works offline. Serialized data often carries user details and session contents, and none of it leaves your device.