Skip to tool
ecech.
💻 Developer & Code

JSON Minifier That Shows Whether Minifying Still Helps After Gzip

Minifying cuts a third of the raw bytes and almost none after gzip, because whitespace compresses away. This measures both, so you know if it is worth doing.

Raw saving

After gzip

Keys

Minified size

Minified



  
Advertisement

How the calculation works

The same JSON, before and after gzip Raw bytes pretty — 7,075 minified — 4,747 minifying saved 33% After gzip pretty — 523 minified — 481 gzip saved only 8% Whitespace is the most compressible thing there is, so gzip removes it either way. Real gzip, measured on a 40-record response. Yours are measured below the same way.

How to Use This Tool

Paste JSON to minify it and see two sizes that matter: the raw saving everyone quotes, and the saving that survives compression, which is the one that reaches the wire.

Why the raw saving is misleading

Minifying JSON removes indentation and line breaks. On a pretty-printed document that is often a third of the bytes, so the raw saving looks impressive. But almost every JSON response travels over HTTP with Content-Encoding: gzip, and gzip is extraordinarily good at exactly the thing minifying removes: repetition. A run of sixteen spaces compresses to almost nothing whether you strip it first or not.

So after compression the two versions are close. In the measured example a 33% raw saving became an 8% saving once gzipped. The whitespace was 33% of the raw bytes and only 8% of the compressed bytes, because gzip had already dealt with most of it. The panels above compute both numbers for your input, so you can see which situation you are in rather than trusting a headline figure.

When minifying is still worth it

  • When the payload is not compressed. Data stored in localStorage, embedded in a URL, written to a database column, or held in memory is usually not gzipped. There the raw saving is the real saving, and minifying is worth it.
  • When you have millions of small documents. A few bytes each, multiplied enough times, adds up even after compression — though at that scale a binary format usually beats JSON entirely.
  • Parsing speed, marginally. Less text is slightly faster to parse, but the difference is tiny next to network time and rarely the reason to do it.
Where minifying actually pays Worth it localStorage, URLs, DB columns, in-memory — usually uncompressed Barely an HTTP API with gzip on — the server already removed the whitespace Check your response headers for Content-Encoding before optimising for size.
The right question is not "how much smaller" but "smaller on which link".

About the gzip figure

The compressed sizes here are real, not estimated. Your browser has a built-in gzip encoder (the same one behind the Compression Streams API), so this runs the actual DEFLATE algorithm on your text and reports the true byte count. The one caveat is the compression level: browsers use a middle setting, and a server tuned to maximum will land a little smaller. Brotli — which many servers now prefer for text — compresses smaller again. So the gzip number is exact for browser-default gzip and a close upper bound for what a well-configured server sends. If your browser is old enough to lack the API, the panel shows "n/a" rather than inventing a figure.

Minifying is safe; formatting is not the same as changing

Removing whitespace does not change what the JSON means — the parsed value is identical, key order is preserved, and numbers are untouched. One thing to know: this re-serialises the data, so any duplicate keys in the input collapse to the last one, which is what a parser would do anyway. If you need to keep the original bytes exactly, keep the original; minify a copy.

Advertisement

Frequently Asked Questions

How much smaller does minifying JSON make it?
The raw saving is often around a third for pretty-printed JSON, since that is roughly how much of it is indentation and line breaks. But if the data is served with gzip, which most HTTP responses are, the saving after compression is usually under 10%, because gzip already removes most of the whitespace. This tool shows both numbers.
Should I minify JSON if my server uses gzip?
Usually it makes little difference. Gzip compresses whitespace almost completely, so the minified and pretty versions end up close in size on the wire. The effort is better spent elsewhere unless you are also serving the data somewhere uncompressed, like localStorage or a URL.
When is minifying JSON actually worth it?
When the data is not compressed: stored in localStorage, embedded in a URL, written to a database column, or held in memory. There the raw byte saving is the real saving. It also helps marginally at very high document counts, though at that scale a binary format usually beats JSON outright.
Is the gzip size shown here exact?
Yes, for browser-default gzip. It uses your browser's built-in gzip encoder — the real DEFLATE algorithm — rather than an estimate, so the byte count is accurate. A server set to maximum compression will land slightly smaller, and Brotli smaller again, so treat it as exact for standard gzip and a close upper bound otherwise.
Does minifying change the data?
No. Removing whitespace leaves the parsed value identical: key order is preserved and numbers are untouched. The only subtlety is that re-serialising collapses any duplicate keys to the last one, which is what a parser does anyway. The meaning of the JSON does not change.
Is minified JSON faster to parse?
Slightly, because there is less text to scan, but the difference is small and almost always dwarfed by network time. Parsing speed is rarely a good reason to minify on its own.
Is my JSON uploaded anywhere?
No. It is parsed, minified and measured in your browser, and nothing is transmitted — which matters because API payloads often contain tokens and personal data.

Related tools in Developer & Code

Browse all Developer & Code tools
The desk where ecech. tools get written: a laptop, a notebook of to-dos and a whiteboard listing the tools on the site.

Made by one person

ecech. is not a content farm. Every tool here is written and checked by hand, one at a time, by someone who wanted the tool to exist and could not find a version that showed its working.

No accounts and no sign-in, and nothing you type reaches a server — every calculation on this page runs inside your browser. The ads are served by Google and do set their own cookies, which is set out in full on the privacy page. More about the site.