Learn & Understand

JSON, Its Alternatives, and How to Stop Shipping Bloated Payloads

The companion calculator reports a JSON payload's size across pretty-printed, minified, and gzipped forms. Those size differences hint at a bigger topic: JSON is the default data format of the web, but it is not always the most efficient one, and much of what makes payloads bloated has nothing to do with formatting. Understanding why JSON won, when a different format serves better, and the real causes of oversized responses, over-fetching and poor pagination, turns a size measurement into a strategy for shipping lean data over the network.

Why JSON Won

JSON became ubiquitous for concrete reasons. It is human-readable, so developers can inspect and debug payloads by eye. It maps naturally onto the data structures of most programming languages, objects and arrays. And it is native to JavaScript, the language of the browser, so web clients parse it effortlessly. These qualities, readability, universality, and browser-native support, made JSON the lingua franca of web APIs, displacing the more verbose XML that preceded it. Its dominance is well-earned for the common case of web APIs where developer convenience and interoperability matter most. But those same qualities, especially being text and self-describing, come at a cost in size.

When Binary Formats Win

JSON's readability makes it verbose: every field name is repeated as text in every record, and everything is stored as characters rather than compact binary. For high-volume or performance-critical systems, binary serialization formats trade human-readability for efficiency.

Formats like Protocol Buffers or MessagePack encode data in a compact binary form, often much smaller and faster to parse, which is why internal microservice communication and mobile apps sometimes prefer them. The trade-off is losing JSON's easy readability and requiring a schema or library. For a public web API, JSON's convenience usually wins; for a high-throughput internal pipeline, a binary format can save real bandwidth and CPU.

The Real Bloat: Over-Fetching

The biggest cause of oversized payloads is usually not the format but sending too much data. Over-fetching is returning far more than the client needs, every field of every record when the client wanted a few fields of a few records. A response stuffed with unused data is wasteful no matter how it is encoded. Modern approaches address this directly: query languages like GraphQL let clients request exactly the fields they need, and well-designed REST APIs offer sparse field selection. Trimming responses to what the client actually uses often shrinks payloads far more than switching formats or compressing would. The cheapest byte to send is the one you do not send.

Pagination and Compression

Two more practices control payload size. Pagination, returning large collections in bounded pages rather than all at once, prevents a single response from ballooning to megabytes and keeps memory and transfer manageable, an endpoint that returns an entire unbounded list is a common bloat and performance problem. And the compression layer, as the calculator shows, can dramatically shrink text payloads because JSON's repetitive structure compresses well, which is one reason JSON's verbosity is tolerable in practice: gzip or Brotli recovers much of the size over the wire. Combining lean field selection, pagination, and compression addresses payload size from every angle.

Shipping Lean Data

Use the calculator to measure a payload's size in each form, and attack bloat where it really lives: appreciate why JSON won for readability and interoperability but consider a binary format for high-throughput internal use, cut over-fetching by returning only the fields and records the client needs, paginate large collections, and rely on compression for text payloads. The calculation measures the bytes; understanding formats and over-fetching is what stops you from shipping bloated ones.