JSON Size Analyzer — Measure JSON Payloads

Find the keys that bloat your JSON

Size is one of the most important properties of a JSON payload, but it is surprisingly hard to reason about. The raw byte count tells you how much storage the document takes, but not how much it actually costs to ship over the network — that depends on gzip. The minified byte count tells you the transport cost without indentation, but not which parts of the document are worth optimizing. Lintify's size analyzer gives you all three numbers, plus a per-key breakdown so you can see exactly which fields are eating your bandwidth.

The four cards at the top of the result show: the raw size of your input, the size after minifying, the size after gzipping (calculated with the browser's built-in CompressionStream API), and the total character count. Below the cards, a bar chart shows each top-level key as a percentage of the total document size — the longest bars are the keys worth optimizing.

Why gzipped size matters more than raw size

Most HTTP traffic is gzipped by default. The bytes that actually travel over the network are closer to the gzipped number than the raw number. The raw size still matters for two reasons: it is what your server stores on disk (in logs, in caches, in backups) and it is what the client parses after decompression. A 10 MB JSON response that gzips to 1 MB still takes 10 MB of memory on the client to parse, which can be a problem on mobile devices.

What to optimize first

The per-key breakdown points at the right keys to optimize. If one key accounts for 60% of the document size, that is where to focus — paginate it, split it into a separate endpoint, or drop fields the client does not need. If no key dominates, the document is roughly balanced and the best optimization is usually pagination or field selection rather than anything fancier.

Avoid the temptation to shorten key names to save space. It almost never helps — gzip already compresses repeated key names very well, and the readability cost in your codebase is real. The same goes for binary formats like MessagePack or CBOR: they are smaller on the wire, but the engineering cost of switching is rarely worth it unless you are operating at serious scale.

How the gzip number is calculated

Lintify uses the browser's built-inCompressionStream('gzip') API to compress the minified JSON. This is the same gzip implementation that browsers use for HTTP transport, so the number is a very close estimate of what your server will actually send. It is not byte-exact — different gzip implementations and compression levels produce slightly different output — but it is close enough for sizing decisions.