JSON Formatter

JSON minifier

Strip every byte of insignificant whitespace from a JSON document and see the before-and-after size in the statistics row. Paste, press Minify, copy or download the result. It all happens in this tab — nothing you paste is uploaded.

Indent

Nothing you paste is uploaded. Minifying is JSON.parse followed by JSON.stringify, both running in your browser. There is no server on this page to send a payload to and no stored copy of anything you type. Why that matters →

What minifying does — and what it does not

JSON has exactly one kind of insignificant character: whitespace between tokens. Space, tab, carriage return and line feed may appear before or after any structural character without changing the meaning of the document. Minifying removes all of it.

That is the whole operation. Everything else in a JSON document is load-bearing:

  • Key names stay. There is no mangling or shortening; renaming "customer_shipping_address" to "a" would break every consumer.
  • Whitespace inside strings stays. The space in "New York" is data, not formatting. Only whitespace between tokens is removed.
  • Values stay. No rounding, no truncation, no dropping of nulls.
  • Order stays, with the one exception every JavaScript-based tool inherits: integer-like keys such as "2" and "10" are hoisted ahead of string keys and sorted numerically, because that is how JavaScript objects enumerate their properties.

Because the output is re-serialised from the parsed value rather than edited as text, minifying is also a validation step: a document that will not parse cannot be minified, and you get the error location instead.

How much do you actually save?

For a typical pretty-printed API payload, whitespace is 15–40% of the bytes. The exact figure depends almost entirely on how deeply nested the document is, because indent cost is proportional to depth × number of lines.

DocumentPretty (2-space)MinifiedSavingGzipped, both
Flat object, 20 keys712 B596 B16%~1% apart
Array of 500 records, 3 levels214 KB137 KB36%~3% apart
Deeply nested config, 6 levels48 KB27 KB44%~4% apart

The last column is the one that changes decisions. Indentation is the most compressible data imaginable — long runs of identical spaces, which DEFLATE encodes in a handful of bits. Once a response is served with Content-Encoding: gzip or br, the difference between pretty and minified on the wire typically collapses to low single-digit percentages.

If your API already gzips its responses, minifying JSON is close to pointless as a bandwidth measure. Check first: curl -sI -H 'Accept-Encoding: gzip' https://your.api/endpoint | grep -i content-encoding. If that prints a value, spend your effort somewhere with a real return.

When minifying genuinely pays

Whenever the JSON is not compressed in transit or at rest:

  • Database columns. A JSONB, TEXT or document-store field usually stores what you give it. Across ten million rows, 40% is real disk, real backup volume and real page cache.
  • Message queues and event streams. Kafka, SQS, Pub/Sub and friends charge by payload size and often enforce a hard per-message limit. SQS caps a message at 256 KB; the difference between 260 KB and 160 KB is the difference between working and not.
  • Cookies, headers and URLs. A cookie is limited to about 4 KB and headers are not compressed on HTTP/1.1 at all. Every byte counts, and JSON in a header should be minified as a matter of course.
  • QR codes and data URIs. Capacity is fixed and small; whitespace directly reduces how much real content fits.
  • Embedded and IoT devices. Where the parser has a fixed buffer and no decompression, size limits are absolute.
  • Anything counted by size. Serverless request payload caps, LLM token budgets, log ingestion pricing.

When not to minify

  • Files people edit. package.json, tsconfig.json, CI configuration. Minified JSON is unreadable and produces unreviewable one-line diffs.
  • Anything in version control. A minified file changes entirely on every edit, so git blame and line-level review stop working. Keep the repository pretty-printed and minify in the build.
  • Log lines you may need to read at three in the morning. Structured logs are usually one compact JSON object per line already, which is a reasonable middle ground.
  • When you have not measured. Minifying an already-gzipped 4 KB response to save 90 bytes is not an optimisation; it is a readability cost with no benefit.

Worked examples

1. Indentation dominates as nesting deepens

Pretty — 178 bytes
{
  "user": {
    "profile": {
      "contact": {
        "email": "a@example.com"
      }
    }
  }
}
Minified — 61 bytes
{"user":{"profile":{"contact":{"email":"a@example.com"}}}}

A 66% reduction, because at four levels deep every one of nine lines carries up to eight leading spaces. The same content flattened into a single object would save under 20%. This is why array-of-flat-records payloads minify far less impressively than configuration trees.

2. Minifying does not shrink the data

A 6 MB export where the bulk is base64 blobs inside string values will minify by perhaps 2%. There is almost no whitespace between tokens to remove — nearly every byte is inside a string. If the payload is too big, minifying is not the lever. The levers are: request fewer fields, page the results, move binary out of JSON and into a separate transfer, or switch that endpoint to a binary format.

3. Minify then check the round trip

Paste the minified output back into the input box and press Format. If it comes back exactly as you started, the round trip is lossless. If a number changed — 9007199254740993 becoming 9007199254740992, or 1.10 becoming 1.1 — that is JavaScript number handling, not the minifier, and it would have happened in your own code too. Large identifiers must travel as strings.

Minifying JSON on the command line

# jq — -c is "compact output"
jq -c . input.json > output.min.json

# Python, standard library, no dependencies
python3 -c 'import json,sys; json.dump(json.load(sys.stdin), sys.stdout, separators=(",",":"))' \
  < input.json > output.min.json

# Node.js
node -e 'process.stdout.write(JSON.stringify(JSON.parse(require("fs").readFileSync(0,"utf8"))))' \
  < input.json > output.min.json

The Python separators=(",",":") argument matters: without it, json.dump writes ", " and ": " and you keep two characters of whitespace per token pair. It is the single most commonly missed detail in Python minification.

Reverse the operation with jq . file.json, python3 -m json.tool, or by pasting the result into the box above and pressing Format.

Frequently asked questions

Does minifying change what my JSON means?

No. Whitespace between tokens carries no meaning in JSON, so removing it produces a document that parses to exactly the same value. The only changes you may observe come from the parse-and-re-serialise round trip rather than from minification: number normalisation (1.50 → 1.5), \u escapes becoming literal characters, duplicate keys collapsing, and integer-like keys being reordered.

Will minifying break my whitespace-sensitive values?

No. Whitespace inside a string is data and is never touched. A value of "line one\nline two" keeps its escaped newline; a value with leading spaces keeps them. Only the gaps between structural tokens go.

Should I minify JSON if I already use gzip?

Usually not for bandwidth. Indentation compresses so well that gzipped pretty and gzipped minified typically land within a few percent of each other. Minify anyway if the JSON is stored uncompressed — in a database column, a queue message, a cookie, a header — or if it must fit under a hard size cap.

Is minified JSON faster to parse?

Marginally, and rarely enough to matter. The parser still has to walk every byte; it just has fewer bytes to skip. On a 1 MB document the difference is typically a few milliseconds. Parse time is dominated by the number of values and by string decoding, not by whitespace.

Can I minify JSON with a regular expression?

Please do not. A regex that strips whitespace outside strings has to track quoting and escaping correctly, and the naive versions destroy any value containing a space, a brace or an escaped quote. Parsing and re-serialising is both correct and faster to write. The same warning applies with more force to regexes that strip comments — they eat the // in every URL they meet.

What is the difference between minified JSON and NDJSON?

Minified JSON is one document with the whitespace removed. NDJSON (also called JSON Lines) is many complete documents, one per line, and is not itself valid JSON. NDJSON is what you want for streaming and for append-only logs, because a consumer can process each line as it arrives without waiting for a closing bracket that may be gigabytes away.

Is the minified output stored or sent anywhere?

No. The input, the parsed value and the output all live in this tab’s memory and are gone when you close it. Download builds the file locally in the page and hands it straight to your browser’s downloader; no upload is involved.

Related pages

Related tools