Serialization

Flow diagram

In computing, serialization (or serialisation, also referred to as pickling in Python) is the process of translating a data structure or object state into a format that can be stored (e.g. files in secondary storage devices, data buffers in primary storage devices) or transmitted (e.g. data streams over computer networks) and reconstructed later (possibly in a different computer environment). When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of objects does not include any of their associated methods with which they were previously linked.

This process of serializing an object is also called marshalling in some situations. The opposite operation, extracting a data structure from a series of bytes, is deserialization (also called unserialization or unmarshalling).

In networking equipment hardware, the part that is responsible for serialization and deserialization is commonly called SerDes.

The Xerox Network Systems Courier technology in the early 1980s influenced the first widely adopted standard. Sun Microsystems published the External Data Representation (XDR) in 1987. XDR is an open format, and standardized as STD 67 (RFC 4506) by IETF.

In the late 1990s, a push to provide an alternative to the standard serialization protocols started: XML, an SGML subset, was used to produce a human-readable text-based encoding. Such an encoding can be useful for persistent objects that may be read and understood by humans or communicated to other systems regardless of programming language. It has the disadvantage of losing the more compact, byte-stream-based encoding, but by this point larger storage and transmission capacities made file size less of a concern than in the early days of computing. In the 2000s, XML was often used for asynchronous transfer of structured data between client and server in Ajax web applications. XML is an open format and standardized as a W3C recommendation.

JSON is a lightweight plain-text alternative to XML and is also commonly used for client-server communication in web applications. JSON is based on JavaScript syntax but is independent of JavaScript and supported in many other programming languages. JSON is standardized as STD 90 (RFC 8259), ECMA-404, and ISO/IEC 21778:2017.

YAML is a strict superset of JSON and includes additional features such as a data type tags, support for cyclic data structures, indentation-sensitive syntax, and multiple forms of scalar data quoting. YAML is an open format.

Property lists are used for serialization by NeXTSTEP, GNUstep, macOS, and iOS frameworks. Property list, or p-list for short, doesn't refer to a single serialization format but instead several different variants, some human-readable and one binary.

For large volume scientific datasets, such as satellite data and output of numerical climate, weather, or ocean models, specific binary serialization standards have been developed, e.g. HDF, netCDF and the older GRIB.

Several object-oriented programming languages directly support object serialization (or object archival), either by syntactic sugar elements or providing a standard interface for doing so. The languages which do so include Ruby, Smalltalk, Python, PHP, Objective-C, Delphi, Java, and the .NET family of languages. There are also libraries available that add serialization support to languages that lack native support for it.

C and C++ do not provide serialization as any sort of high-level construct, but both languages support writing any of the built-in data types, as well as plain old data structs, as binary data. As such, it is usually trivial to write custom serialization functions. Moreover, compiler-based solutions, such as the ODB ORM system for C++ and the gSOAP toolkit for C and C++, are capable of automatically producing serialization code with few or no modifications to class declarations. Other popular serialization frameworks are Boost.Serialization from the Boost Framework, the S11n framework, and Cereal. MFC framework (Microsoft) also provides serialization methodology as part of its Document-View architecture.

With the introduction of reflective programming to C++26, serialization has been greatly simplified. Reflection allows for compile-time serialization of, for instance, JSON into a struct with corresponding structure.

CFML allows data structures to be serialized to WDDX with the <cfwddx> tag and to JSON with the SerializeJSON() function.

Delphi provides a built-in mechanism for serialization of components (also called persistent objects), which is fully integrated with its IDE. The component's contents are saved to a DFM file and reloaded on-the-fly.

Go natively supports unmarshalling/marshalling of JSON and XML data. There are also third-party modules that support YAML and Protocol Buffers. Go also supports Gobs.

In Haskell, serialization is supported for types that are members of the Read and Show type classes. Every type that is a member of the Read type class defines a function that will extract the data from the string representation of the dumped data. The Show type class, in turn, contains the show function from which a string representation of the object can be generated. The programmer need not define the functions explicitly—merely declaring a type to be deriving Read or deriving Show, or both, can make the compiler generate the appropriate functions for many cases (but not all: function types, for example, cannot automatically derive Show or Read). The auto-generated instance for Show also produces valid source code, so the same Haskell value can be generated by running the code produced by show in, for example, a Haskell interpreter. For more efficient serialization, there are haskell libraries that allow high-speed serialization in binary format, e.g. binary.

Java provides automatic serialization which requires that the object be marked by implementing the java.lang.Thread object is tied to the state of the current JVM. There is no context in which a deserialized java.lang.Thread object would maintain useful semantics.
Secondly, the serialized state of an object forms part of its class' compatibility contract. Maintaining compatibility between versions of serializable classes requires additional effort and consideration. Therefore, making a class serializable needs to be a deliberate design decision and not a default condition.
Lastly, serialization allows access to non-transient private members of a class that are not otherwise accessible. Classes containing sensitive information (for example, a password) should not be serializable nor externalizable. The standard encoding method uses a recursive graph-based translation of the object's class descriptor and serializable fields into a byte stream. Primitives as well as non-transient, non-static referenced objects are encoded into the stream. Each object that is referenced by the serialized object via a field that is not marked as transient must also be serialized; and if any object in the complete graph of non-transient object references is not serializable, then serialization will fail. The developer can influence this behavior by marking objects as transient, or by redefining the serialization for an object so that some portion of the reference graph is truncated and not serialized.
Java does not use constructor to serialize objects. It is possible to serialize Java objects through JDBC and store them into a database. While Swing components do implement the Serializable interface, they are not guaranteed to be portable between different versions of the Java Virtual Machine. As such, a Swing component, or any component which inherits it, may be serialized to a byte stream, but it is not guaranteed that this will be re-constitutable on another machine.

Since ECMAScript 5.1, JavaScript has included the built-in JSON object and its methods JSON.parse() and JSON.stringify(). Although JSON is originally based on a subset of JavaScript, there are boundary cases where JSON is not valid JavaScript. Specifically, JSON allows the Unicode line terminators U+2029Point implements the serde::Serialize and Cline, Marshall. "C++ FAQ: "What's This "Serialization" Thing All About?"". Archived from the original on 2015-04-05. It lets you take an object or group of objects, put them on a disk or send them through a wire or wireless transport mechanism, then later, perhaps on another computer, reverse the process, resurrecting the original object(s). The basic mechanisms are to flatten object(s) into a one-dimensional stream of bits, and to turn that stream of bits back into the original object(s).

↑ "Python 3.9.6 documentation - Python object serialization —pickle". Documentation - The Python Standard Library.

↑ "Serialization". www.boost.org.

↑ Peter Dimov, Dan Katz, Brry Rezvin, Daveed Vandevoorde (19 June 2025). "Splicing a base class subobject". isocpp.org. WG 21.{{cite web}}: CS1 maint: multiple names: authors list (link)

↑ "proto · pkg.go.dev". pkg.go.dev. Retrieved 2021-06-22.

↑ Bloch, Joshua (2018). "Effective Java: Programming Language Guide" (third ed.). Addison-Wesley. ISBN 978-0-13-468599-1.

↑ "JSON". www.json.org. Retrieved 22 March 2018.

↑ "TC39 Proposal: Subsume JSON". ECMA TC39 committee. 22 May 2018.

↑ "HDF5.jl: Saving and loading data in the HDF5 file format". 20 August 2017 – via GitHub.

↑ "SERBENCH by aumcode". aumcode.github.io.

↑ "PHP: Serializable - Manual". www.php.net.

↑ ""Term input/output"". gprolog.org.

↑ "pickle — Python object serialization — Python v3.0.1 documentation". docs.python.org.

↑ Eddelbuettel, Dirk; Stokely, Murray; Ooms, Jeroen (2014). "RProtoBuf: Efficient Cross-Language Data Serialization in R". Journal of Statistical Software. 71 (2). arXiv:1401.7372. doi:10.18637/jss.v071.i02. S2CID 36239952.

↑