What Is Deserialization?
Deserialization is the counterpart to serialization: it rebuilds a usable object from the bytes that represent it. But what is deserialization exactly, and how does deserialization work? We'll go over all the details — including the security risks to watch for — in this article.
What Is Deserialization? How Does Deserialization Work?
Deserialization is the process of reconstructing a data object from a series of bytes, recreating the original in-memory object so that an application can read and modify it as a native structure in its programming language. It reverses serialization: where serialization flattens an object into a portable byte stream, deserialization parses that stream and rebuilds the object's fields, types, and structure.
For deserialization to succeed, the reading side generally needs to know the format the data was written in, and — depending on the codec — may need access to the corresponding class definitions. A mismatch between the serialized data and the expected type is a common source of runtime errors.
Serialization vs. Deserialization
Serialization and deserialization are two halves of the same round trip. An object is serialized when it is saved or sent, and deserialized when it is loaded or received. For example, writing a Java object to a distributed cache serializes it on the way in, and reading it back deserializes it on the way out.
The two operations almost always use the same format on both ends. Mixing formats — for instance, serializing with one codec and attempting to deserialize with another — produces corrupt or unreadable data, so consistency of the codec across applications is essential.
The Security Risks of Deserialization
Deserialization deserves special care, because rebuilding an object from bytes can trigger code paths influenced by the incoming data. Deserializing data from untrusted sources is a well-known class of vulnerability — often called insecure or unsafe deserialization — that can lead to remote code execution when an attacker supplies a maliciously crafted payload. Native Java serialization is particularly exposed to this risk.
Safer practices include only deserializing data from trusted sources, preferring data-only formats such as JSON, validating expected types before and after deserialization, and choosing codecs that do not blindly instantiate arbitrary classes from the input.
Deserialization in Redis, Valkey, and Redisson
Because Redis and Valkey hold data as raw bytes, every read of a Java object involves deserialization. A client such as Redisson performs this automatically: when you fetch a value from a distributed map, queue, or other object, Redisson reads the bytes from Redis or Valkey and deserializes them back into a Java object using the configured codec.
Redisson's default Kryo5Codec handles both serialization and deserialization, and the same codec must be used for writing and reading a given object. Developers who need JSON's readability, cross-language interchange, or stricter control over which types are instantiated can switch to Jackson or another supported codec, either globally or per object. See the Redisson data serialization guide for configuration details.