JSON and data serialization, explained simply

The problem underneath JSON

A running program holds data in memory as objects, pointers, and typed values - a JavaScript object, a Python dict, a Java class instance. None of that structure survives being sent over a network. A network connection can only carry a stream of bytes; it has no idea what "an object" is.

Serialization is the process of flattening a rich, in-memory structure into something that can actually travel - usually text, sometimes raw binary. Deserialization is the reverse: taking those bytes back and rebuilding the structure on the other end. Every APIAPIA defined way for one piece of code to ask another to do something, without needing to know how it happens internally. Not a specific technology - a function signature, a library's exports, and a REST endpoint are all APIs. call, every file save, every message queueMessage queueA component that lets one part of a system hand off work to another without waiting for it to finish immediately - the sender moves on right away, and a separate worker processes the job whenever it gets to it. payload involves this round trip, whether or not anyone thinks about it explicitly.

Why JSON specifically won

{
  "id": 42,
  "name": "Ada",
  "active": true,
  "roles": ["admin", "editor"]
}

JSON (JavaScript Object Notation) became the default serialization format for web APIs for a fairly boring but decisive reason: it's readable by a human without any tooling, it maps closely onto how most languages already represent objects, arrays, strings, numbers, and booleans, and it's lightweight compared to the XML it mostly replaced.

XML technically does more - namespaces, schemas, attributes versus elements - but that extra structure came at a real cost in verbosity and parsing complexity, for benefits most web APIs never needed. JSON won by being just enough format for the common case.

What gets lost in translation

Serialization isn't lossless, and this is the part that causes real bugs.

JSON has exactly one number type - no distinction between an integer and a float, and no way to represent a number larger than roughly 2^53 without losing precision. A 64-bit ID or a financial amount that needs exact decimal precision can silently corrupt if you're not careful, which is why large IDs are often sent as strings instead of numbers in real APIs.

JSON has no date type at all. Every timestamp you've ever seen in a JSON payload is a string, by convention (usually ISO 8601), not something JSON itself understands - parsing it back into an actual date object is entirely up to whichever code reads it.

The clearest way to see the loss is to send an object through the full round trip and compare what comes back. Everything JavaScript knows about types has to fit through a string in the middle:

1const user = {2  id: 42,3  name: "Ada",4  createdAt: new Date("2024-01-15T09:30:00Z"),5  nickname: undefined,6  tags: new Set(["admin", "editor"]),7  greet() {8    return "hi";9  },10};11 12const wire = JSON.stringify(user);13// '{"id":42,"name":"Ada","createdAt":"2024-01-15T09:30:00.000Z","tags":{}}'14 15const received = JSON.parse(wire);16 17typeof received.createdAt; // "string", not a Date18"nickname" in received;    // false - the key is not in the text at all19received.tags;             // {} - an empty object, not a Set20typeof received.greet;     // "undefined" - the method is gone

Content negotiation: how the two sides agree on format

A server can usually respond in more than one format, and the client says which one it wants using the Accept header, while the server states what it's actually sending back using Content-Type:

Accept: application/json
Content-Type: application/json; charset=utf-8

This is content negotiation - a small, easy-to-miss mechanism that lets the same endpoint serve JSON to one client and, say, XML to a legacy one, without either side needing to guess.

Beyond JSON: when text isn't good enough

JSON's readability is also its cost - every key name gets repeated in every single object, brackets and quotes add overhead, and parsing text is slower than parsing raw bytes. For high-throughputThroughputThe total amount of work a system completes over a given period - requests per second, jobs processed per hour. Optimizing for throughput can sometimes make individual latency worse, and vice versa. systems (service-to-service calls inside a data center, for instance), binary formats like Protocol Buffers or MessagePack trade human-readability for smaller payloads and faster parsing, at the cost of needing a shared schema both sides agree on ahead of time.

Most APIs never need this tradeoff. But it's worth knowing it exists, because "why isn't this JSON" is a legitimate design decision in high-performance systems, not just an obscure alternative nobody uses.