JSON Minifier_
One line, no spaces, same data. Every byte the minifier removes is whitespace a parser was going to discard anyway, so the value that comes out is identical to the value that went in — and the readout above says exactly how many bytes went, in case the answer matters less than you expect.
It usually does matter less than you expect. On a typical API payload, flattening a pretty-printed document removes about a third of the file, and roughly a fifteenth of what actually crosses the network once gzip is switched on. Both figures are worth having before you wire a minifier into a build step.
- Input
- Any JSON that parses — a pretty-printed config, an editor-formatted response, a document already on one line. Invalid input is refused rather than partly stripped, because a half-minified broken document is harder to fix than the original.
- Output
- The same value on a single line, with every space, tab and newline between tokens gone. Whitespace inside a string is untouched: it is data, not layout.
- Processing
- Parsed and re-serialised in this tab, which is the only reason it is safe to paste a live response here. Nothing is posted anywhere and nothing is stored.
- Limits
- Minifying is lossless for the value and lossy for the layout — comments do not survive because RFC 8259 has none to survive, and key order is preserved exactly as written.
- The number most pages do not show you
- Whitespace compresses extremely well, so a gzip layer has already removed most of what a minifier removes. On a 120-row catalogue payload the file shrinks 37.2% raw and 6.7% after gzip — measured, not estimated. Minify because a build step or a size limit demands it, not because you assume the wire is a third lighter.
What a JSON minifier actually saves
A third of the file, a fifteenth of the transfer
Take a catalogue response — 120 records, each with an identifier, a name, a price, a couple of tags and a timestamp — and serialise it twice, once indented at two spaces and once flat. Indented it is 29,420 bytes; flat it is 18,484. That is 37.2% removed, which is the number every minifier on the web will happily show you.
Now send both through gzip, as every web server and every HTTP client has done by default for two decades. The indented version becomes 2,157 bytes and the flat one 2,013. The saving is 6.7%. Under brotli it is 6.4%. The reason is not subtle: indentation is a long run of identical characters, and long runs of identical characters are the single thing a compressor is best at. The minifier and the compressor are largely doing the same job, and the compressor got there first.
Which makes it worth doing anyway, for other reasons
Compression is not always in the path. A JSON document embedded in a bundle, written into a database column, pushed as a message body, stored in localStorage, or passed as an environment variable is stored raw — and there the full third is real. Payload size limits are usually written against raw bytes too: a queue that refuses messages over 256 KB counts what you hand it, not what a compressor could have made of it. So the honest rule is that minifying pays where the bytes are stored or counted, and pays very little where they are merely sent.
What is removed, and what is deliberately not
Only whitespace between tokens goes: the newline after a comma, the two spaces before a key, the space after a colon. Whitespace inside a string stays exactly as it was, because there it is content — {"note": "see below"} keeps both spaces, and a tool that collapsed them would be corrupting your data rather than compacting your file. Nothing else changes: numbers keep their written form, key order is preserved, and Unicode escapes are neither added nor resolved.
Minifying is not compressing, and not obfuscating
Three words get used interchangeably and mean different things. Minifying removes characters the format does not need and leaves text a human can still read. Compressing replaces the bytes with a shorter encoding that has to be reversed before anything can read it. Obfuscating deliberately makes the content hard to understand — and minified JSON does none of that, since every key and every value is still sitting there in plain sight. A minified payload is exactly as readable to anyone who receives it, which matters if you were hoping otherwise.
At the command line, and in a build
jq -c . file.json is the shortest route on a machine that has jq, and -c is the whole flag — compact output. Without jq, python3 -c 'import json,sys;json.dump(json.load(sys.stdin),sys.stdout,separators=(",",":"))' does the same, and the separators argument is the part people forget: leave it out and Python writes a space after every comma and colon, which is not minified at all. In JavaScript it is simply JSON.stringify(value) with no third argument. In an editor, VS Code has no built-in command for it, which is why the search exists.
Paste it, watch the percentage, take the line
- 01Paste the JSON, or use Upload to read a local file. It minifies as you type, so there is no button to press first.
- 02Read the row above the panes: the size before, the size after, the bytes removed, and the share of the original that went.
- 03If the input is invalid, the error replaces the readout instead of showing a saving — a document that does not parse has no minified form.
- 04Copy takes the single line; Download writes it as a .json file. Both carry the whole result even when the pane is showing less.
A payload a few bytes over the queue limit
Message queues and serverless request bodies are counted in raw bytes, before any compression the transport might apply. When a document is just over the line, the indentation is the cheapest thing to remove and often enough on its own.
{
"event": "order.created",
"orderId": 88213,
"lines": [
{ "sku": "A-1", "qty": 2 }
]
}{"event":"order.created","orderId":88213,"lines":[{"sku":"A-1","qty":2}]}A config blob going into a text column
A database column stores exactly what you hand it and there is no compressor in the path, so the whole saving is real and it repeats on every row.
{
"retries": 3,
"timeoutMs": 2500,
"endpoints": {
"primary": "eu-west-1",
"fallback": "us-east-1"
}
}{"retries":3,"timeoutMs":2500,"endpoints":{"primary":"eu-west-1","fallback":"us-east-1"}}A fixture that rewrites the whole diff
Change one value in a pretty-printed fixture and the diff can run to a hundred lines. Flattened, the same change is one line — harder to read alone, far easier to review inside a pull request full of other work.
{
"user": {
"id": 7,
"role": "editor"
}
}{"user":{"id":7,"role":"editor"}}Something that has to survive as one line
An environment variable, a shell argument, a CI secret, a form field that eats newlines. None of these can hold a multi-line document, and the flat form is the only shape that arrives intact.
{
"db": {
"host": "localhost",
"port": 5432
}
}{"db":{"host":"localhost","port":5432}}The same payload, measured four ways
| Form | Bytes | Against indented raw |
|---|---|---|
| Indented, 2 spaces | 29,420 | — |
| Minified | 18,484 | 37.2% smaller |
| Indented, then gzip | 2,157 | 92.7% smaller |
| Minified, then gzip | 2,013 | 93.2% smaller |
| Minified, then brotli | 1,119 | 96.2% smaller |
A 120-record catalogue response, measured rather than estimated. Read the last three rows together: compression does the heavy lifting, and minifying first adds 0.5 percentage points on top of it.
Habits worth having around a minifier
- Check whether compression is already on before you add a minify step to a build. If the response carries
content-encoding: gzip, the saving you are chasing is a few per cent, not a third. - Keep the indented copy in version control and minify on the way out. A flat file is fine for a machine and miserable in a code review, and the transformation costs nothing to repeat.
- Minify last, after any step that reads the file. Tools that parse JSON do not care about layout, but tools that pattern-match lines very much do.
- If the goal is a smaller payload rather than a smaller file, look at the data before the whitespace — repeated keys, embedded base64, and timestamps written three ways cost far more than indentation ever did.
- Watch the percentage on your own documents rather than trusting a rule of thumb. Deeply nested configuration loses far more to indentation than a flat array of long strings does.
Where minifying disappoints or misleads
It is not a security measure
Every key and value survives in plain text on one line. Anyone who can read the response can still read the API keys, the internal identifiers and the debug fields somebody left in. Removing newlines removes newlines.
Comments do not survive, because they were never valid
JSON has no comment syntax. If your file has // or /* */ in it, it is JSONC or JSON5 — a different format — and it will be reported as invalid here rather than silently stripped, because quietly deleting something you wrote is worse than refusing.
The percentage flatters the file, not the transfer
A minifier that advertises "up to 40% smaller" is measuring raw bytes with compression switched off. That number is true and mostly irrelevant to a browser fetching over HTTPS, where the same document arrives about seven per cent lighter.
One line means one line in error messages too
A parser that reports "unexpected token at line 1, column 18,442" is technically correct and useless. Keep an indented copy of anything you may have to debug, or format it again when something breaks.
Grammar, sizes, and what runs where
- Grammar
- RFC 8259. Comments, trailing commas, single-quoted strings and unquoted keys are not JSON and are rejected as errors rather than removed.
- Method
- The text is parsed to a value and re-serialised with no indent argument, so the output is whatever a strict serialiser produces — never a regular expression run over the source.
- Measurement
- Sizes are UTF-8 bytes, not characters. A document full of accented or CJK text costs two or three bytes per character, and a character count would overstate what reaches the network.
- Preserved
- Key order, number formatting as written, string contents including any whitespace inside quotes, and Unicode escapes exactly as they appear.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about minifying JSON
How much smaller does minifying JSON actually make a file?
About a third for a typical indented payload — 37.2% on the 120-record example measured on this page. Deeply nested documents lose more, because every level of nesting adds indentation to every line; a flat array of long strings loses much less. The readout above gives the figure for your own document, which is worth more than any average.
Does minifying JSON help if the server already uses gzip?
Barely. Indentation is a long run of repeated spaces, and that is precisely what a compressor eliminates first, so most of the saving has already happened before the minifier runs. On the measured example the gain drops from 37.2% to 6.7% once gzip is applied, and to 6.4% under brotli. It is still a real saving, just a small one.
Is minified JSON still valid JSON?
Yes, and identically so. Whitespace between tokens carries no meaning in the grammar, so removing it produces a document that parses to exactly the same value. Anything that accepted the indented form accepts the flat one.
What happens to comments in my JSON file?
The file is rejected. JSON has no comments — the format never defined them — so a file containing them is JSONC or JSON5 rather than JSON, and stripping them silently would delete something you deliberately wrote. Remove them first if you meant to, or keep the commented file as the source and generate the JSON from it.
How do I minify JSON on the command line?
jq -c . file.json, where -c means compact. Without jq, python3 -c 'import json,sys;json.dump(json.load(sys.stdin),sys.stdout,separators=(",",":"))' works anywhere Python is installed — and the separators argument is essential, because the default writes a space after every comma and colon and produces something that is not minified.
How do I minify JSON in VS Code?
There is no built-in command, which is why people search for one. The Format Document command does the opposite. An extension can add it, or you can select the document and run it through jq with a task — but for a single file, pasting it here is faster than configuring either.
Does minifying change my data in any way?
No. The value that comes out is the value that went in: same keys, same order, same numbers, same strings down to the spaces inside them. Only the layout between tokens is different, and layout is not part of what JSON stores.
Should I minify JSON that goes into a database?
Usually yes, because a database column stores what you hand it and there is no compressor in the path. The full saving is real and it repeats on every row. The one argument against is debugging — a flattened blob is unpleasant to read in a query result, so keep the choice deliberate rather than automatic.
Does my JSON leave the browser?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.