Does Minifying JSON Matter If You Use Gzip?

The advice is everywhere: minify your JSON before sending it over the wire, because whitespace is wasted bandwidth. The arithmetic is real — a pretty-printed document is usually 40–50% larger than the same data minified.

The advice also skips a step. Almost every HTTP response is compressed with gzip or brotli before it is sent, and repeated whitespace is the single most compressible thing in a text file. The question is not how many bytes minifying removes. It is how many bytes minifying removes that the compressor would not have removed anyway.

So I measured it.

The measurement

The test document is an array of records with six fields each — an ordinary API response shape: an integer id, two short strings, a boolean, a float and a small array. Pretty-printing is two-space. Compression is gzip at level 6 (the common default) and brotli at its default.

Records	Pretty	Minified	Raw saving	Saving after gzip	Saving after brotli
25	4,542 B	2,459 B	45.9%	11.1%	17.3%
500	92,864 B	51,356 B	44.7%	3.3%	15.5%
5,000	948,447 B	533,439 B	43.8%	3.5%	10.5%

Read the 500-record row again. Minifying removed 41,508 bytes of raw payload and 197 bytes of transferred payload. The compressor had already found almost all of it.

Why the saving shrinks as the file grows

Notice that the gzip saving falls from 11.1% at 25 records to 3.3% at 500. That is not noise — it follows directly from how DEFLATE works.

Gzip encodes repeated byte sequences as back-references to earlier occurrences. Indentation is the most repetitive content imaginable: the same run of spaces, thousands of times, at predictable intervals. The first few occurrences cost real bytes while the compressor builds its dictionary; every one after that costs a few bits. So the larger the document, the closer the marginal cost of whitespace gets to zero, and the less there is for minifying to save.

Small payloads are the exception, and for the opposite reason — the dictionary never gets going, so the whitespace is still being paid for.

Brotli behaves differently, and it is worth knowing why

Brotli produces much smaller output than gzip in every row above — 2,931 bytes against 5,915 on the 500-record document. But the *proportional* benefit of minifying is larger under brotli: 15.5% versus 3.3%.

That looks backwards until you look at the absolute numbers. Brotli squeezed the whole document so much harder that the remaining bytes are mostly irreducible data — so the few hundred bytes that minification removes are a bigger slice of a much smaller pie. In absolute terms brotli saved 453 bytes to gzip's 197. Both are rounding errors on a 92 KB response.

When minifying genuinely matters

Relocating the benefit is not the same as dismissing it. Minify when raw size is the thing being paid for:

Storage. A JSON column in Postgres or MySQL, a document in MongoDB, a value in Redis. Nothing is gzipping that for you, and 44% is 44%.
Size-capped messages. SQS has a 256 KB limit, Kinesis 1 MB, Lambda payloads 6 MB. Whitespace can be the difference between fitting and not.
localStorage and IndexedDB. Browser quotas count raw characters.
Uncompressed transports. Plenty of internal services, embedded devices and IoT links do not negotiate compression at all.
Log lines. One record per line, often stored raw and billed by volume.

And one thing that matters far more than any of this: check that compression is actually on. An origin serving JSON without Content-Encoding is leaving 90%+ on the table, next to which minification is a rounding error. One command tells you:

curl -s -H 'Accept-Encoding: gzip, br' -o /dev/null -D - https://example.com/api/items | grep -i content-encoding

No output means no compression, and that is the bug worth fixing today.

What minifying does not do

Minification removes insignificant whitespace between tokens. That is all. It is worth being precise, because people expect more from it than it delivers:

Assumption	Reality
It strips nulls	No. `"note": null` survives intact.
It drops empty arrays and objects	No. `[]` and `{}` stay.
It shortens keys	No — and long repeated keys are usually the real cost. Gzip handles them very well, which is another argument for compression over minification.
It speeds up parsing	Marginally at best. Parse time tracks the number of values, not the whitespace between them.
It obscures the payload	No. It is one click from readable, and anything sensitive is still right there.

Whitespace *inside* a string is data and is never touched: "New York" keeps its space.

A reasonable default

Turn on gzip or brotli at the server or CDN. This is the whole game.
Store and commit formatted JSON. A minified file in a repository is one enormous line — unreviewable, unmergeable.
Minify at the point of transmission or storage, as a build or serialization step, when measurement says it helps.
Never minify anything a person is expected to read or edit.

You can measure your own document in the browser with the JSON minifier, which reports the exact byte counts for your data rather than an estimate, and restore it with the formatter. Both run locally — nothing is uploaded.