JSON Minifier
Strip every unnecessary byte and see exactly what you saved.
JSON Raw Input
Minified Output
What minifying actually saves
Minifying removes every byte of whitespace that sits between tokens — the newlines, the indentation, the space after each colon. The data is untouched; only the presentation goes. On a formatted document with two-space indentation the saving is typically 15–30%, and deeper nesting means more indentation and therefore more to remove.
Whether that saving matters depends on transport. If your server sends JSON with gzip or brotli — and it almost certainly should — compression already collapses repetitive whitespace very efficiently, so minifying first adds much less than the raw percentage suggests. Where it does count is uncompressed contexts: values stored in a database column, embedded in a URL, or held in localStorage.
The byte counts above are measured in UTF-8, not characters, which is the number that actually travels over the wire. Any non-ASCII content in your document makes those two figures diverge.
What minification actually does to your JSON
The document is parsed into a real data structure and then serialised back out with no indentation and no separator padding. It is not a text substitution, which is why whitespace inside string values survives intact while the whitespace between tokens disappears.
{ "msg" : "hello world", "n" : [ 1, 2 ] }
→ {"msg":"hello world","n":[1,2]}Because the input has to parse before it can be re-serialised, the minifier doubles as a validator: malformed JSON is rejected with the parser's own error rather than silently producing a smaller but broken document.
Where the savings actually come from
Two-space indentation costs two bytes per nesting level per line, and a newline costs one more. Deeply nested documents therefore compress far better than flat ones — an array of small objects nested four levels deep can shed 40% of its size, while a flat object of long string values may shed under 5%, because the strings themselves dominate.
When not to bother
If the JSON is served over HTTP with gzip or brotli enabled, most of the benefit is already taken: compression algorithms handle repeated whitespace extremely well, and minifying first typically buys only a few further percent. Minification earns its place where compression is not in the path — values stored in a database column, packed into a URL parameter, written to localStorage, or embedded in a QR code, where every byte is counted literally.
Frequently asked questions
Does minifying lose any data?
No. The JSON is parsed and re-serialised without whitespace, so every key and value survives. Only formatting is discarded — and the change is reversible with the formatter.
How much smaller does JSON get?
Usually 15–30% for a document formatted with two-space indentation. Deeply nested structures save more because they carry more indentation per line.
Should I minify if my server already uses gzip?
Usually it is not worth much. Compression handles repeated whitespace very well, so most of the saving is already captured. Minify where compression is absent — database fields, URL parameters, localStorage.
Are the byte counts characters or bytes?
UTF-8 bytes, which is what is actually transmitted. For ASCII-only content the two match; any accented or non-Latin character makes bytes exceed characters.
Can I get the formatting back?
Yes. Minifying only removes whitespace, so running the result through the JSON formatter restores a readable layout.
Is whitespace inside my strings preserved?
Yes, and this is the distinction that separates a real minifier from a find-and-replace. Only structural whitespace between tokens is removed. A value such as "hello world" keeps all three spaces, because the JSON is parsed into data and re-serialised rather than having spaces stripped from the text.
Does minifying change numbers or key order?
Key order is preserved. Numbers are normalised by the JSON parser, so 1.50 becomes 1.5, 1e2 becomes 100, and a value beyond the precision of a 64-bit float will be rounded — which matters if you are carrying large integer IDs. Store identifiers longer than 15 digits as strings to keep them exact.
What happens to duplicate keys and comments?
JSON has no comments, so anything resembling one is a syntax error and will be reported rather than stripped. Duplicate keys are technically allowed by the specification but the last value wins when parsed, so a duplicate silently disappears during minification — worth knowing if your source was machine-generated.