%22%2F%3E%3Cg%20fill%3D%22none%22%20stroke%3D%22%23fff%22%20stroke-width%3D%226%22%20stroke-linecap%3D%22round%22%3E%3Cpath%20d%3D%22M14%2020h36%22%2F%3E%3Cpath%20d%3D%22M26%2032h24%22%2F%3E%3Cpath%20d%3D%22M38%2044h12%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
FormatKitFree online JSON minifier
Minify JSON and count what it saved
This JSON minifier costs nothing and asks for no account: hand it up to 5 MB and it strips every space and newline between tokens, then tells you exactly what that was worth — bytes before, bytes after, the percentage, and the gzip size measured by your own browser rather than guessed. On a typical two-space document the saving is about 37%, and about 17% of that survives gzip, which is the number worth knowing before you bother. Drop a folder in and every file gets its own row and its own download, with a total at the bottom.
- 100% free
- No signup
- Up to 5 MB
- Real gzip size
- 40 files at once
Sorting does not change the byte count — it makes two payloads compress and diff alike.
One line of JSON, as small as it goes.
Paste JSON, or choose several files at once to see what a whole folder would save.
What minifying is worth on five real payload shapes
Each row is a two-space document measured against its own minified form, with gzip at level 6 applied to both. The pattern is consistent: the more structure and the less prose a payload carries, the more whitespace it was holding — and the less of that saving survives compression.
| Payload | Pretty | Minified | Saved | Saved after gzip |
|---|---|---|---|---|
| Array of 400 order records | 309,092 B | 192,691 B | 37.7% | 15.3% |
| GeoJSON, 300 point features | 86,779 B | 41,767 B | 51.9% | 7.5% |
| Nested service config | 5,704 B | 3,422 B | 40.0% | 16.7% |
| Lockfile, 250 packages | 70,763 B | 55,747 B | 21.2% | 1.7% |
| 200 records of prose | 63,432 B | 59,831 B | 5.7% | 2.2% |
How to minify JSON
Three steps, and a number at the end of each one.
Paste one payload, or hand over a folder
Paste the JSON, use the paste shortcut, which reaches this panel from anywhere, or press Weigh files and select up to 40 at once. A single file goes into the editor; several turn into a table with a before, an after and a percentage on every row and a total at the bottom.
Read the four counters, not just the first
Bytes removed and the percentage are the obvious pair. The two beside them matter more: the gzip figure is your own browser compressing your own data at zlib's default level 6, the setting nginx uses for dynamic responses, and the brotli estimate scales that measurement by 0.59, the ratio measured across six payload shapes at quality 11.
Take the small version
Copy puts the single line on the clipboard, Download saves it as .min.json, and in a batch every row that parsed gets its own Download. Rows that failed keep their line number and reason instead of a size, so a folder with one broken file still gives you the other thirty-nine.
Technical specifications
| Measured saving | 37.5% off a 2-space document and 51.5% off a 4-space one, measured on a 5.0 MB array of order records (8,156,447 bytes → 5,100,946) |
|---|---|
| Saving after compression | 1.7% to 17.6% depending on shape — the same edit is worth far less once gzip has seen it |
| Gzip figure | Exact, not estimated: computed in your browser by CompressionStream, which compresses at zlib's default setting of level 6 — the level nginx and most CDNs apply to dynamic responses |
| Brotli figure | Estimated as gzip × 0.59, the mean ratio measured over six JSON shapes at quality 11 (range 0.44 to 0.72) |
| Compression floor | Gzip costs 18 bytes of header and trailer, so a 71-byte document leaves it at 88 bytes; brotli leaves it at 62 |
| Batch mode | Up to 40 files at once, each with its own before, after and percentage, plus a total row and a per-row download |
| What is removed and what is not | Every space, tab and newline between tokens, and the space after each colon. Whitespace inside strings, key order, duplicate keys and number literals are untouched |
| Limits and price | 5 MB per document, 500 levels of nesting; free, no signup, and every byte is counted inside your browser |
Frequently asked questions
How much smaller does minifying JSON actually make a file?
About 37% off a document indented with two spaces, and 51.5% off one indented with four — measured on a 5.0 MB array of order records, where 8,156,447 bytes came down to 5,100,946. The saving is entirely the whitespace, which is 37.8% of a two-space document, so it scales with how deeply nested the data is rather than with how much data there is: a GeoJSON feature collection of short coordinate arrays lost 51.9%, while a file of long prose strings lost 5.7%.
Is minifying JSON worth it when the server already gzips the response?
Usually much less than you would hope, because whitespace is the most compressible thing in a file. The same 5 MB payload that loses 37.5% of its raw bytes only loses 17.6% after gzip, and on a lockfile the figure collapses to 1.7% — the compressor was already encoding those runs of spaces as almost nothing. Minify anyway when the bytes are not compressed on the path you care about: a value in localStorage, a column in a database, a string embedded in HTML, or an environment variable.
Why is my gzipped JSON bigger than the file I started with?
Because gzip has a fixed cost of 18 bytes for its header and trailer, plus a few for the deflate block, and a small payload cannot earn that back: a 71-byte JSON object comes out of gzip at 88 bytes. The crossover for typical JSON sits somewhere around 150 to 200 bytes. Brotli's header is smaller — the same 71-byte object compresses to 62 — which is one of several reasons it wins on small responses.
Does minifying change the data or break anything?
No. Whitespace between tokens carries no meaning in RFC 8259, so removing it leaves an identical document — the same keys in the same order, the same duplicate keys, the same number literals down to the trailing zeros of 1.500. What minifying does change is diffability: a one-line file gives git nothing to align, so every edit shows as one changed line, which is why the minified copy belongs in the build output rather than in the repository.
How small can a JSON payload actually get?
Whitespace is the free win, and after that you are changing the data rather than the formatting. In a minified array of order records, the key names and their colons account for 46.3% of every byte, and the structural punctuation — braces, brackets, commas, colons — for another 14.2%, so shortening property names or moving to an array-of-arrays with a header row saves several times what stripping spaces did. That is a schema change with real costs, and it is worth doing only after compression has been ruled out.
Can minified JSON be turned back into readable JSON?
Yes, exactly, because minifying only removes bytes that never meant anything. Paste the one-liner into the prettifier and it comes back as an indented tree with every value intact; there is no lossy step in either direction. The one thing that does not come back is your original layout — if you had aligned columns or handwritten line breaks in particular places, those were whitespace too and they are gone.
Will a minified payload fit in localStorage?
It has roughly 5 MB per origin to fit into, and the accounting is stricter than it looks: Chrome and Firefox measure the quota in UTF-16 code units, so a plain-ASCII payload spends two bytes of budget per character. A 2.4 MB minified document therefore uses most of the allowance on its own, and exceeding it throws a QuotaExceededError rather than silently truncating. The counter under the tool shows the percentage before and after so you can see whether minifying alone gets you under.
About the size of a JSON payload
Minifying JSON is the cheapest optimisation there is and one of the easiest to over-value. The raw win is real and repeatable — 37.5% off a two-space document, 51.5% off a four-space one — because indentation is 37.8% of the bytes in a nested payload and none of them carry meaning. What changes the calculation is that those bytes are also the most compressible content in the file: a run of fourteen spaces is one of the cheapest things a deflate window can encode, so by the time gzip has finished, the same edit is worth 17.6% on a large record array and 1.7% on a lockfile. If the response travels with Content-Encoding on it, minifying is a rounding error dressed up as an optimisation.
Where it stops being a rounding error is everywhere the bytes are stored rather than sent. localStorage gives an origin about 5 MB and Chrome counts it in UTF-16 code units, so ASCII costs double and a comfortable-looking 2.4 MB document is already most of the budget. A JSON column in a database is stored as you wrote it. So is a payload embedded in a page inside <script type="application/json">, which has the additional trap that the sequence </script inside any string value ends the element early no matter how valid the JSON is — the fix is to escape it before embedding, not to hope it never appears. The same applies to a JSON blob in an environment variable, where AWS Lambda allows 4 KB for a function’s entire environment and a pretty-printed config will not fit twice over.
When whitespace is gone and the file is still too big, the remaining bytes are the data and its labels. In a minified array of order records, key names and their colons are 46.3% of every byte and structural punctuation is another 14.2%, which is why the next real win is always shorter keys or a columnar shape — one header row and arrays of values instead of the same twelve property names repeated ten thousand times. That is a schema change, with everything that implies for the code on both sides, and it is worth reaching for only after compression has been tried. If you are going the other way and need to read one of these files again, the prettifier puts the whitespace back with nothing lost in between.
Where the weighing happens
Every byte counted on this page is counted locally: the parser, the minifier and the CompressionStream that produces the gzip figure all run inside your browser tab, so neither the payload nor the files you drop in are uploaded anywhere. That is also why the gzip number is exact rather than estimated — it comes from your own machine compressing your own data.