Compress JSON by stripping every optional space, tab and line break, and get the whole document back as one line. Minifying is a size optimisation, not a data change — the output parses to exactly the same object. Paste, press Minify, copy the result. Everything happens in your browser; nothing is uploaded.
A JSON minifier removes the insignificant whitespace between tokens — the line breaks,
the indentation, the space after each colon and comma — and returns the document as a
single line. That is the whole operation. It does not remove keys,
shorten or round values, drop nulls, or change any type: 4900
stays a number, "4900" stays a string. Parse the minified output and you get
an object that is deep-equal to the one you started with.
{
"id": "evt_8842",
"type": "order.paid",
"created": 1754438400,
"data": {
"amount": 4900,
"currency": "usd",
"items": [
{
"sku": "A1-KEYBOARD",
"qty": 2
},
{
"sku": "B7-CABLE",
"qty": 1
}
]
},
"livemode": false
}{"id":"evt_8842","type":"order.paid","created":1754438400,"data":{"amount":4900,"currency":"usd","items":[{"sku":"A1-KEYBOARD","qty":2},{"sku":"B7-CABLE","qty":1}]},"livemode":false}Both documents are pure ASCII, so characters and bytes are the same count. The 115 bytes that disappeared break down exactly: 19 line breaks, 84 spaces of indentation, and one space after each of the 12 colons. Nothing else was touched — same 12 keys, same values, same order.
How much of a pretty-printed file is whitespace depends entirely on its shape. Documents dominated by long string values save the least — prose contains no removable indentation. Documents built from many small records save the most, because nearly every line is mostly leading spaces. The usual band is 10–30% of the raw bytes, with record-shaped data pushing past 50%.
Then compression enters, and the picture changes. Repeated indentation is the easiest
thing in the world for gzip and brotli to eat: the same newline-plus-four-spaces sequence
appears thousands of times and costs almost nothing after the first. Take this site's own
manifest.webmanifest: pretty-printed it is 1,347 bytes and minified it is
1,005 — a 25% cut. Gzipped, those same two files are 504 and 471 bytes. The real saving
over the wire is 33 bytes, about 7%, not 342.
So minifying for HTTP is mostly theatre if you already have compression on. Where it wins outright is everywhere the bytes are stored, quoted or encoded exactly as written.
| Context | Helps? | Why |
|---|---|---|
| HTTP response with gzip or brotli | Barely | Compression already collapses repeated indentation. Expect single-digit percentages, not the raw-byte figure. |
| localStorage and cookies | Yes | Stored verbatim against a hard ceiling: roughly 5 MB per origin, about 4 KB per cookie — and cookies are re-sent on every matching request. |
| Environment variables, CI secrets | Yes | Injected as raw strings, never compressed, and most providers cap the size of a single variable or secret. |
URL query parameters, data: URIs |
Yes | Percent-encoding turns each space into %20, so whitespace costs triple; base64 then adds a further third on top. |
| Database column | Depends | A text or json column keeps your bytes exactly as written. A binary column such as Postgres jsonb reparses on write, so whitespace is discarded either way. |
| Message-queue payloads | Yes | Brokers enforce a hard per-message size and often bill by volume, and most transports do not compress message bodies by default. |
| JSON inside an HTML attribute | Yes | Every quote in the payload has to be escaped anyway; line breaks and indentation are pure noise in the middle of markup. |
| Line-delimited logs (NDJSON) | Required | One object per line is the format. A pretty-printed record would break the parser outright, not merely waste space. |
The rule of thumb: if something further down the path already compresses the bytes, minifying buys you very little. If the JSON is stored, quoted, encoded or counted as-is, minifying buys you the whole difference.
.json file onto the page..json file. The toast tells you how many bytes you saved.A browser tool is quickest for something you just copied out of a log. For a file already on disk, or for a build step, these are the equivalents.
# jq — -c is compact output
jq -c '.' in.json > out.json
# Python — the separators argument is the whole point
python3 -c 'import json,sys; json.dump(json.load(open("in.json")), sys.stdout, separators=(",",":"))' > out.json
# Python 3.9+ ships a flag for it
python3 -m json.tool --compact in.json out.json
# Node.js — no dependencies
node -e 'process.stdout.write(JSON.stringify(require("./in.json")))' > out.json
That separators argument is the part everyone forgets. With no
indent, json.dumps defaults to (', ', ': ') — a
space after every comma and every colon. On the sample above that leaves 21 stray
spaces behind: 203 bytes instead of 182. Pass
separators=(',', ':') and you get a genuine minifier.
// JavaScript — the third argument is what adds whitespace, so omit it
JSON.stringify(value);
# Python
json.dumps(value, separators=(',', ':'))
Go needs no flag at all: json.Marshal is compact by default and
json.MarshalIndent is the opt-in. One caveat applies to every approach here,
including this page's tool: minifying parses the text and re-serialises it, so numbers are
rewritten. That is invisible almost always, but an integer beyond 253 or a value
written as 1.0 can come back changed.
Files under version control. A one-line file turns every change into a
full-file diff: your reviewer sees 1 line changed and has no way to tell whether you fixed
a typo or rewrote the schema. git blame collapses to a single row naming
whoever last touched anything, and a merge conflict has to be resolved by hand across the
entire document. Commit JSON pretty-printed and let the build minify it.
Files a human has to edit. Config, fixtures, seed data, translation catalogues, editor settings. Nobody edits a 40 KB single line; they format it first, change one value, and now the diff is the whole file again.
Anything already served with gzip. As measured above, the wire saving is a few percent — rarely worth trading readability for.
None of this is a one-way door. Minified JSON is still perfectly valid JSON — whitespace between tokens is optional in the grammar, so every parser reads it identically — and the operation is fully reversible. Paste the single line into the beautifier or the formatter, pick an indent width, and your structure is back. Compact for transport, expand for reading, as often as you like.
No. A minifier only removes whitespace between tokens, so the output parses to an object that is deep-equal to the input. Keys, values, array order and types all survive. The one edge case is numeric precision: because the text is parsed before it is rewritten, an integer larger than JavaScript can represent exactly may come back rounded.
Usually 10 to 30 percent of the raw bytes, and past 50 percent for documents built from many small records with short keys. Text-heavy documents save the least, because long string values contain no removable whitespace. The 20-line sample on this page drops from 297 bytes to 182, a saving of 115 bytes or 39 percent.
Yes. Whitespace between tokens is optional in the JSON grammar, so a single-line document is exactly as valid as an indented one. Every parser, API and database accepts it with no special handling.
Rarely for that reason alone. Compression handles repeated indentation extremely well, so the gain over the wire is typically a few percent rather than the 20 or 30 you see in the raw byte count. Minify instead where the bytes are stored or encoded uncompressed: local storage, cookies, query strings, environment variables and queue messages.
Run it back through a formatter. Minifying is fully reversible because nothing but whitespace was removed, so pasting the single line into the beautifier and picking an indent width restores a readable document. There is no lossy step to undo.
No. The minifier is JavaScript running in your browser and it makes no network request with your content. API responses, access tokens and customer records never leave your machine.