Backend

Serialization and Deserialization Explained: How Data Travels Between Systems

Code to Ship
2026-02-05
8 min read

Every time a client talks to a server, something subtle but critical happens behind the scenes.

Data changes its shape.

A Javascript app sends data. A backend written in Rust, Go, or Java receives it. The data crosses machines, networks, and languages and still somehow makes sense on the other side.

That doesn’t happen by accident.

It happens because of serialization and deserialization.

This article explains what those words actually mean, why they exist, and how data moves safely between completely different systems.

The Core Problem: Different Languages, Different Worlds

Let’s start with a real situation.

  • The client is a Javascript application
  • The server is written in Rust

In Javascript, you might have:

{ "name": "John" }

This is a Javascript object.

But Rust:

  • Is statically typed
  • Is compiled
  • Does not understand Javascript object

Rust works with structs, strict types, and explicit memory layouts.

So here’s the question:

How does a Javascript object travel over the internet and turn into a Rust struct on another machine?

That question is the heart of serialization.

What Actually Travels Over The Network

Before answering that, it’s important to understand one thing:

Objects do not travel over the internet.

  • Not Javascript objects
  • Not Rust structs
  • Not Python dictionaries

Network only move bytes.

So everything no matter how complex must eventually becomes a sequence of bytes.

A Quick Note on the OSI Model (Just Enough)

Data doesn’t jump directly from client code to server code. It passes through multiple layers.

Conceptually: Application Layer (Client Code) -> Other OSI Layers (Transport, Network, Physical) -> Application Layer(Server Code)

You don’t need to manage these layers manually but they explain why data must be converted into a transferable form.

The application layer needs a format that:

  • Can be turned into bytes
  • Can survive transmission
  • Can be reconstructed later

The Need For A Common Standard

Since machines and languages are different, client and server must agree on a shared format.

This format must be:

  • Language agnostic
  • Platform independent
  • Easy to encode and decode

This agreement is called a serialization standard.

What Is Serialization?

Serialization is the process of: Converting in-memory data into common format suitable for transmission or storage

Example: Javascript Object:

{ "name": "John" }

Serialized into JSON:

{"name":"John"}

Now it’s just text. Text can be converted into bytes. Bytes can travel over the network.

What Is Deserialization?

Deserialization is the reverse process. Converting the common format back into language specific data structure.

On the server side:

  • JSON bytes arrive
  • They are parsed
  • They are converted into a Rust struct

Example (conceptually):

struct User {
name: String,
}

Now the server can safely perform business logic.

Serialization Is Language Agnostic by Design

The key idea: The network does not care about your programming language.

Serialization exists so that:

  • Javascript can talk to Rust
  • Rust can talk to Python
  • Python can talk to Java etc

As long as both sides agree on the format, communication works.

Where Serialization Happens In Real Requests

Consider HTTP POST request.

On the client side

  1. JavaScript creates an object
  2. The object is serialized into JSON
  3. JSON is placed in the request body
  4. Headers describe the format

Example:

POST /users
Content-Type: application/json
{"name":"John"}

On the server side

  1. Server receives raw bytes
  2. Reads Content-Type
  3. Chooses the correct parser
  4. Deserializes JSON into a native data structure
  5. Executes business logic

Sending The Response Back

The process repeats in reverse.

  1. Server creates a response object
  2. Serializes it into JSON
  3. Sends it over HTTP
  4. Client parses JSON
  5. Client converts it into Javascript objects
  6. UI renders the data

This symmetry is intentional.

Common Serialization Formats

JSON (Most Common)

  • Text-based
  • Human-readable
  • Language-agnostic
  • Supports nested structures

Example:

{
"user": {
"id": 1,
"name": "John"
}
}

This is why JSON dominates HTTP APIs.

XML and YAML Also text-based formats.

  • XML: verbose,schema-heavy
  • YAML: human-friendly, indentation-sensitive

Binary Formats Example:

  • Protocol Buffers
  • Avro

Characteristics:

  • Compact
  • Faster to parse
  • Not human readable

Often used in:

  • gRPC
  • Internal microservice communication

Serialization Beyond HTTP

Serialization is not limited to HTTP.

It is used in:

  • WebSockets
  • gRPC
  • Message queues
  • Databases

For example:

  • PostgreSQL serializes rows to disk
  • MongoDB serializes documents

Storage and transmission share the same fundamental problem

Final Thoughts

Serialization and Deserializations are not the advanced concept. They are foundational ones.

Understanding this helps you:

  • Debug request issues
  • Understand API failures
  • Choose the right data format

Once you understand that:

  • Network moves bytes
  • Languages understand structures
  • Standards connect the two

A lot of backend communication suddenly becomes clear.

Every API request you send is really just a careful transformation from memory, to bytes and back again.