JSON Minify
Removes insignificant whitespace from JSON. Measured on a 3,000-record payload: 753,012 bytes down to 462,011 — 38.6% off, and the minified text is byte-identical to what the pretty file parses to.
Ctrl / Cmd + Enter formats as well.
Click any { } or [ ] to collapse or expand it. The number beside a bracket is its item count, so an empty array is obvious at a glance. Rendering stops at 5,000 nodes.
Paste JSON into the Format & validate tab first.
Supported: $, .key, ..key (recursive descent), [0] and [*]. That is the subset developers actually use, not the whole JSONPath grammar.
Compared structurally, not as text. Indentation, key order and 1.0 vs 1 are not reported as differences.
The data comes from the input box on the Format & validate tab. Supported: type, required, properties, items, enum, const, numeric bounds, string length and pattern, array length and uniqueness, and additionalProperties. Not supported yet: $ref, allOf/anyOf/oneOf and format.
Minifying JSON deletes the whitespace between tokens and nothing else — not inside strings, not the key order, not the number values. That is checked rather than promised: for the payload measured above, the minified text is byte-identical to JSON.stringify(JSON.parse(pretty)). What can still change is the round trip itself, and the formatter page lists all six ways that happens.
The savings are real and bounded: 38.6% on the 2-space file measured above. If someone tells you minification will halve your payload, they are describing a file with unusually generous indentation.
How much it actually saves
Same generated payload in both directions — 3,000 records, ten
fields each, some nested — measured in Chrome 152 / Windows 11 with
TextEncoder for byte counts and CompressionStream("gzip") for the
compressed column:
| Form | Bytes | vs pretty |
|---|---|---|
| Pretty printed, 2-space indent | 1,375,892 | — |
| Minified | 829,891 | −40% |
| Pretty printed, then gzip | 11,498 | −99% |
| Minified, then gzip | 9,924 | −99%, and about 14% under the row above |
Read the last two rows together, because that is the useful finding: once gzip is on the wire, minifying first buys roughly 14% more, not 40%. Whitespace is exactly the thing a general-purpose compressor was looking for.
Two honest qualifications. This sample is repetitive synthetic data, so its gzip ratio
is better than a real API response will be — and if the transport is HTTP/2 with
Content-Encoding: gzip or br, you are already paying for
compression, which is where the comparison applies.
Do not use minification as obfuscation
Minified JSON is one long line, which is inconvenient to read in a text editor. It is not unreadable: any formatter turns it back, and a browser's dev tools do it on click. If the content is sensitive, the answer is transport security and access control, not whitespace.
The related trap runs the other way. Because a minified file is one line, tools that report errors by line number become useless — "line 1, column 4,182,309" is technically correct and practically painful. That is a reason to keep a pretty copy in version control and minify only at build or deploy time.
Frequently asked questions
Is minifying lossy?
Not for a valid JSON document: the same value comes out. It is lossy for comments and formatting, which is one more reason JSONC files should not be minified with a JSON tool — the comments are stripped by the parser, not preserved.
How much smaller will my file get?
Around 40% for 2-space output, more for 4-space or tab-indented files, and nothing for a file that is already minified. The measured numbers are in the table above.
Should I minify before or after compression?
Before, if you control the pipeline — it never hurts and it is cheap. But do not expect much: on the measured sample, gzip already takes the pretty file down by 99% and minifying first adds about 14%.
Does minifying make it unreadable on purpose?
No, and do not count on it for secrecy. One click in any formatter, including this site, restores the indentation.