JSON Minifier

What actually gets removed

Only whitespace that a parser ignores: the spaces, tabs and newlines between tokens. Whitespace *inside* a string is data and is never touched — "New York" keeps its space, and a string containing a newline keeps it too.

Everything else stays. Minifying does not shorten keys, drop nulls, remove empty objects or reorder anything, and the result is ordinary, fully valid JSON that any parser reads identically to the original.

{
  "id": 1,
  "name": "New York",
  "tags": []
}

{"id":1,"name":"New York","tags":[]}

How much you save

The saving depends entirely on the shape of the document, not its size. Whitespace scales with the number of lines and the depth of nesting, so a deeply nested document with short values is mostly whitespace, while a flat document with long strings is barely affected.

Forty-odd percent is typical for record-shaped data at two-space indentation, and it rises sharply with indentation width — the same document at four spaces is 58% whitespace. Those are real measurements, not estimates; the page shows you the exact numbers for your own document.

What happens after compression

This is the part most minification advice leaves out, and it changes the decision completely. Almost every HTTP response is already compressed with gzip or brotli — and repeated whitespace is the single most compressible thing there is. By the time your JSON reaches the wire, the compressor has removed most of what minifying would have removed.

That does not make minifying pointless — it relocates the benefit. It still matters where compression is absent or where raw size is what counts: rows in a database column, values in localStorage, documents in a queue message with a hard size cap, log lines, or an embedded device with no gzip at all. Check that your server has compression enabled first; if it does not, that is worth far more than minifying.

What minifying will not fix

Minifying is re-serialization too

The document is parsed and written out again, which means it normalises the same things formatting does. Worth knowing before you minify a file you intend to keep:

• 1.0 becomes 1, and 1e3 becomes 1000.
• "\u0041" becomes "A".
• Duplicate keys collapse — the last one wins and the others are gone.
• Integers beyond 2^53 lose precision, silently.

The operation is otherwise lossless and reversible: run the output through the beautifier and you get a readable document back. What you cannot recover is the original indentation style, because that information no longer exists anywhere.

Minifying in a build or a pipeline

For anything repeatable, do this at the command line rather than by hand. jq -c is the standard answer and it is already installed on most machines.

# One file, in place
jq -c . input.json > output.json

# Every JSON file in a directory
find . -name '*.json' -exec sh -c 'jq -c . "$1" > "$1.min"' _ {} ;

# Convert a formatted array into NDJSON — one record per line
jq -c '.[]' records.json > records.ndjson

# In Node, with no dependencies
node -e 'process.stdout.write(JSON.stringify(require("./input.json")))'

That third command is worth knowing. NDJSON — one minified document per line — is what log pipelines, BigQuery, and most streaming loaders actually want, and it is strictly better than a single giant array for anything processed record by record, because a consumer can read one line at a time instead of parsing the whole file into memory.

When not to minify

• Files in a repository. A minified file is one enormous line. Every change shows as the whole file changed, code review becomes impossible, and merge conflicts are unresolvable.
• Configuration people edit. Readability is the entire point.
• Anything you are debugging. Minify last, if at all.
• Responses served with compression, unless you have measured and the numbers justify it.

The reasonable default is to store and commit formatted JSON, minify at the point of transmission or storage if measurement says it helps, and never minify anything a person is expected to read.