How to minify JSON
- Paste your formatted JSON into the box above.
- The minified version appears immediately below.
- Check the reported saving, indented documents typically shrink by a third.
- Copy the result, or download it as a .json file.
- Keep your formatted copy as the version people edit.
What minifying does
- Removes every space, tab and line break between tokens.
- Validates the JSON on the way through, so broken input is reported not mangled.
- Reports the exact character saving as a number and a percentage.
- Preserves key order and array order exactly.
- Leaves string contents untouched, including any spaces inside them.
- Runs entirely in your browser with nothing uploaded.
Where minified JSON earns its place
Whitespace in JSON exists for humans. Machines ignore it entirely, so every space and line break in a payload is bandwidth spent on nothing. A typical indented document is around a third larger than its minified form, and deeply nested ones can be half as large again.
On a single request that is irrelevant. Across an API serving millions of responses, or a configuration file loaded on every page view, it adds up to real money and real load time.
When to minify
- API responses, particularly ones fetched repeatedly by a front end.
- Configuration embedded in a web page or shipped in a JavaScript bundle.
- Values stored in a database column with a length limit.
- Data sent over a metered or slow connection, such as to a mobile client.
- Anything passed through a URL parameter, where every character counts twice after encoding.
When not to bother
Files people edit should stay formatted. A minified configuration file is a file nobody can review, and the saving is meaningless for something read once at startup. The same applies to fixtures, seed data and anything that lives in version control, where a minified document produces a single-line diff that hides what actually changed.
It is also worth knowing that if the response is served with gzip or brotli compression, which almost everything is. The transport layer has already removed most of the benefit. Whitespace compresses extremely well because it is so repetitive. Minifying still helps, particularly for storage and for anything not compressed in transit, but the gain over gzip alone is smaller than the raw percentage suggests.
What minifying does not change
The data is identical. Key order is preserved, arrays keep their order, string contents including internal spaces are untouched, and the minified document parses to exactly the same value.
Number formatting is the single exception. Re-serialising normalises 1.50 to 1.5 and 1e3 to 1000, because those are the same number to a parser. If the precise written form matters. A version string, an account number with leading zeros. It should have been stored as a string, and this is a good moment to notice that.
Keep both versions
The sensible workflow is to treat the formatted document as the source and minify on the way out, exactly as build tools do for CSS and JavaScript. Editing minified JSON by hand is miserable and error-prone.
Use the JSON formatter to go back the other way, or the JSON validator when something will not parse. Everything runs locally, so payloads containing tokens or customer records are never uploaded.
Minifying is not the same as compacting a structure
A payload can be minified and still wasteful. Long descriptive key names repeat on every object in an array, so a thousand records carrying customerEmailAddress spend forty thousand characters on that one label. Deeply nested wrappers add braces without adding information, and null-valued keys occupy space to say nothing at all.
Whitespace removal cannot help with any of that. If a response is genuinely too large, look at the shape before the formatting: shorten repeated keys, omit nulls rather than transmitting them, and flatten a wrapper that exists only for historical reasons. Those changes routinely halve a payload where minification saves a quarter, and they compound with it rather than competing.