Serialize and Unserialize Data Converter Tool

Serialized data is the byte-by-byte text representation of a value — a string, number, array, or object — that has been flattened into a single linear string so it can be stored or transmitted, then rebuilt back into its original structure later. In PHP specifically, this is the job of the built-in serialize() function, and the format it produces is often just called "PHP serialized data" or "a serialized array."

The defining trait of PHP's serialization format, compared to JSON or XML, is that it is self-describing at the byte level. Every value is preceded by a single-letter type marker and, for strings, an explicit byte length. That's why a serialized string looks like s:4:"John"; instead of simply "John" — the s says "this is a string," the 4 says "exactly four bytes follow," and everything inside the quotes is the literal payload.

This length-prefixing is a deliberate design choice. It means the parser never has to guess where a string ends by scanning for an unescaped quote character — it just reads four bytes and stops, which makes the format fast to parse and resistant to certain string-escaping bugs that plague naive JSON or CSV parsers. The tradeoff is that serialized strings become fragile the moment a human edits them by hand, because changing the value without recalculating the length breaks the entire structure.

Anatomy of a serialized array

Take the associative array ['name' => 'John', 'age' => 30]. Running it through serialize() produces:

a:2:{s:4:"name";s:4:"John";s:3:"age";i:30;}

Reading it left to right: a:2: means "an array with 2 key-value pairs follows." Then each pair is written as key, then value, both wrapped in their own type:length:value triplets, with the whole array closed by a final curly brace.

Serialized objects look almost identical

Objects use the same pattern but start with O instead of a, and include the class name and property count:

O:4:"User":2:{s:4:"name";s:4:"John";s:3:"age";i:30;}

That extra "User" after the property count is the class name PHP needs to reconstruct the right object type when it unserializes the string back — which is also exactly why mixing serialized objects between codebases, or unserializing data from an untrusted source, deserves caution (more on that in the security section below).

Unserialized data is simply the original value — restored. It's what you get after running a serialized string back through PHP's unserialize() function: the flat, length-prefixed text turns back into a real, usable array, object, string, integer, boolean, or null that your application can loop over, read properties from, or pass into other functions exactly as if it had never left memory in the first place.

It helps to think of serialize and unserialize as a matched pair, the way zip and unzip are a matched pair. Serializing flattens a structure into a transportable string; unserializing inflates that string back into the original structure. If the round trip is done correctly, unserialize(serialize($value)) and $value are functionally identical.

Why "unserialized" isn't a single fixed format

This is the part that trips a lot of people up: once you've unserialized a value, you still need to decide how to look at it or output it, and PHP — and this converter — give you several different views of that same underlying value:

• print_r output — a clean, indented, human-readable tree. No type information, no quotes around strings beyond what you'd naturally expect. This is what most developers reach for first when debugging.
• var_dump output — the same structure, but annotated with explicit data types and string byte-lengths for every single value. This is the version to use when a bug might be caused by a type mismatch, like a numeric string "30" being mistaken for an integer 30.
• var_export output — valid, runnable PHP source code that, if pasted directly into a script, recreates the exact same value. This is the version to use when you want to hard-code a fixture, a config default, or a test case.

The converter generates all three views from the same input, so instead of mentally translating between formats, you can simply pick whichever representation answers the question you're actually asking right now.

Why so many formats?

In a real codebase, the same piece of data routinely passes through several of these formats in a single request lifecycle: a query string arrives over HTTP, gets parsed into an array, is serialized for storage in a session or cache, and may eventually be exposed to a frontend as JSON or to a partner system as XML. Having one tool that speaks all six input dialects and all eight output dialects removes the need to context-switch between a JSON formatter, a separate PHP sandbox, and a manual XML editor just to trace one value through that pipeline.

It also means you can use the converter as a translation layer between systems that were never designed to talk to each other directly — for example, taking a legacy serialized PHP column and producing the JSON payload a modern JavaScript frontend actually expects, without writing a migration script for a single one-off check.

Serialization isn't a niche technique reserved for advanced PHP work — it's quietly running underneath some of the most common operations in web development. Understanding where it shows up makes it much easier to recognize a serialized string the moment you see one, instead of mistaking it for corrupted data or a bug.

Session storage

By default, PHP stores $_SESSION data on disk as a serialized string between requests. Every time a user logs in, adds an item to a cart, or moves through a multi-step form, PHP is serializing that session array behind the scenes and unserializing it back on the next request.

Caching layers

Tools like Memcached and Redis, when used through PHP's caching libraries, frequently store complex values — query results, computed objects, API responses — as serialized strings, because serialization is fast and preserves exact PHP types without the overhead of a full database round-trip.

Database columns

It's extremely common to find a single database column holding a serialized array instead of a normalized set of columns or a separate table — WordPress's wp_options table is a well-known example, where plugin settings, theme configuration, and widget data are all stored as serialized PHP arrays in a single option_value column.

REST API payloads

Modern APIs almost always exchange JSON, not PHP-serialized data — but the backend logic generating that JSON is frequently working with native PHP arrays and objects internally, which means converting between JSON and PHP structures (in both directions) happens constantly during API development and debugging.

Config and options storage

Application settings, feature flags, and user preferences are often stored as a single serialized blob rather than dozens of individual rows, because it keeps related settings grouped together and avoids constant schema changes every time a new setting is added.

Legacy data migration

When moving data out of an older PHP application — into a new framework, a different language entirely, or a modern JSON-based API — serialized columns need to be unserialized first and then re-encoded into a portable format like JSON or XML before they're usable anywhere else.

This is one of the most common questions developers run into once they realize PHP gives them two completely different ways to flatten a value into a string. The short answer: use JSON when data needs to leave PHP, and use serialize() when data is staying inside PHP. The longer answer depends on what you're optimizing for.

JSON is a language-independent standard. A JSON string produced by PHP can be parsed natively by JavaScript in the browser, by Python on a data pipeline, by a mobile app written in Swift or Kotlin, or by virtually any modern programming language without a special library. That universality is exactly why REST APIs settled on JSON as the default exchange format.

PHP's serialize() format, on the other hand, is PHP-specific by design. It can represent things JSON simply has no syntax for — like which class an object was instantiated from, or which properties were declared private versus public. That extra fidelity is valuable when data never leaves PHP, but becomes a liability the moment another language needs to read it, because that language has no native way to interpret O:4:"User":2:{...}.

Serialization is safe in the overwhelming majority of everyday use — reading config values, debugging a session, converting between formats for a script you control. The risk shows up specifically when unserialize() is called on data that came from somewhere untrusted: a query parameter, a form field, a cookie, or any other input an attacker could potentially shape.

What is PHP Object Injection?

Because a serialized object string can specify any class name available in the application — O:9:"SomeClass":... — an attacker who controls the string passed into unserialize() can potentially instantiate classes that were never meant to be created from user input. If any of those classes define "magic methods" like __wakeup(), __destruct(), or __toString(), those methods run automatically the moment the object is built or destroyed — which is the foundation of a class of attacks known as PHP Object Injection (sometimes chained into full remote code execution depending on what those magic methods do).

This isn't a flaw in the serialization format itself — it's a consequence of trusting input that hasn't been validated. The same caution that applies to SQL injection or unsanitized file paths applies here: never feed external input directly into a function that can act on it without restriction.

How to stay safe

• Never unserialize raw user input. If a value needs to come from a request, prefer JSON (json_decode()) for anything user-facing, since JSON has no concept of arbitrary class instantiation.
• Use the allowed_classes option. Since PHP 7.0, unserialize() accepts a second argument that restricts which classes (if any) are allowed to be instantiated — passing false blocks all objects outright.
• Sign or encrypt data you control but store externally, such as in a cookie, so a tampered string is rejected before it ever reaches unserialize().
• Treat this converter, and any online tool, as a read-only inspection utility for understanding and reformatting data you already have — not as a substitute for proper input validation in production code.