What it removes and what it cannot
Minifying JSON removes the characters between tokens: indentation, newlines, and the space after a colon or comma. That is the entire list. Key order, numeric precision and string contents are untouched, because they are data rather than formatting.
There is nothing else to squeeze. JSON has no comments to strip and no shorter syntax to switch to — unlike JavaScript, where a minifier also renames variables and rewrites expressions.
Where it actually matters
Most JSON travels over HTTP with gzip or brotli applied, and compression already handles repeated whitespace well. The places minification still earns its keep are the ones where no compression happens:
- JSON embedded in an inline
<script>tag - A
data-attribute holding a configuration blob - A value going into a URL, a cookie, or a QR code, where a hard length limit exists
- Anything stored in
localStorage, which is size-capped per origin
The round trip
Minified and formatted JSON are the same document. Nothing prevents you formatting the output again later — this is not a lossy operation, and there is no reason to keep an unminified copy for safety.
Questions
Does minifying change my data?+
No. The document is parsed into real values and printed back with no formatting, so what comes out is byte-for-byte equivalent as data — same keys, same numbers, same nesting. Only whitespace disappears.
How much smaller does it get?+
Typically 15–30% for indented JSON, more for deeply nested documents where every level adds leading spaces. The status bar shows the exact figure for your input rather than a promise.
Should I minify JSON in an API response?+
It is already the default in every serious framework, and gzip removes most of the remaining difference anyway. Minifying matters most where compression is not applied: an inline script tag, a data attribute, a URL parameter, a QR code payload.
Can I get the formatting back?+
Yes — nothing is lost. Run the result through the [JSON formatter](/t/json-formatter) and pick an indent.