JSON Minifier

Strip insignificant whitespace from JSON — values and key order byte-identical, gzip savings measured, entirely on this device.

0 bytes uploaded

The minifier changes whitespace only — never key order, never values.

JSONInput — paste JSON here

Output — minified JSON

0 B · 0 lines · JSON

Press ? for shortcuts

Do it offline:$ jq -c . file.json

How to use it

Paste JSON, or drop a .json or .txt file up to 50 MB — small inputs minify as you type; past 2 MB a button states the size before running.
Read the savings line under the output: original bytes, minified bytes, percentage saved, and — where supported — the gzipped weight of the result.
Invalid JSON emits nothing: the message names the line, column and probable cause, a code frame points at the character, and your paste stays put.
Copy the result, download a .json file, or Share the tool state as a link — a link carries only what you explicitly put in.

Paste pretty-printed JSON and the one-line version appears immediately, with a byte count that tells the whole story: original size, minified size, and what the minified bytes weigh after gzip. Stripping whitespace touches nothing else — keys keep their order, numbers keep every digit — and the work happens on this device, so nothing you paste is ever transmitted.

Examples

{
  "service": "checkout",
  "port": 8443,
  "features": {
    "retries": 3,
    "timeoutMs": 2500,
    "tls": true
  },
  "hosts": [
    "eu-1.internal",
    "eu-2.internal"
  ]
}

{"service":"checkout","port":8443,"features":{"retries":3,"timeoutMs":2500,"tls":true},"hosts":["eu-1.internal","eu-2.internal"]}

A 2-space config collapses to one line; the savings line reads 180 B → 129 B · saved 28% · 123 B gzipped. Gzip is measured with Node's zlib here — your browser's CompressionStream can differ by a few bytes.

{"cache":{"ttl":60,"keys":["a:1","b:2"]},"hits":1024}

{"cache":{"ttl":60,"keys":["a:1","b:2"]},"hits":1024}

Input and output are byte-for-byte identical, so the status line reports Already minified — saved 0 bytes instead of inventing a number.

{
  "note": "line one\n    line two",
  "padded": "three   spaces   stay",
  "id": 1541815603606036481,
  "name": "caf\u00e9"
}

{"note":"line one\n    line two","padded":"three   spaces   stay","id":1541815603606036481,"name":"caf\u00e9"}

Everything between quotes survives untouched — the \n spelling and the three-space runs included — while the snowflake ID keeps all nineteen digits and \u00e9 stays a six-character escape.

Every example on this page is executed against the same engine that powers the tool, on every build.

Gotchas worth knowing

\u00e9 is never rewritten to é

Collapsing an escape into its character leaves the parsed value identical, so some minifiers do it for a few extra bytes. Not here: tokens are re-emitted exactly as written — \u00e9 stays escaped, 1E+2 keeps its exponent — because byte-level rewrites surprise anything that hashes, signs or diffs a file.

Long numbers cannot be corrupted here

No number conversion exists on the output path: digits pass straight through, and a 19-digit snowflake ID or nanosecond timestamp emerges intact. Minifiers that round-trip through JSON.parse quietly round such integers.

What gzip does to the savings

Minification looks dramatic until compression joins in. A 13.6 KB pretty-printed log extract drops to 9.3 KB minified — 31% saved — yet gzipped the two versions weigh 1.1 KB and 978 B, about 12% apart. Indentation is exactly the repetition gzip eats for free — so minify for parsers, quotas and pipelines, not for transfer size.

Duplicate keys pass through, loudly

Minifying {"env":"prod","env":"stage"} emits both pairs unchanged and raises a warning naming the key and both lines — dropping a pair would change your document. The JSON Validator page covers why repeated names are an interoperability trap.

The size ladder up to 50 MB

Small pastes minify on every keystroke; from 256 KB the work moves to a background thread, and from 2 MB the page waits for an explicit press that states the size. Beyond 50 MB it declines the whole input and hands you the CLI line instead — a minified slice would be a different document.

Common errors

Unexpected '}' at line 1, column 15 — probable cause: trailing comma after the last property.: A comma promises another property, so the closing brace arrives too early. Common in hand-edited configs — remove the final comma and the document minifies.
Unexpected "'" at line 1, column 9 — probable cause: single-quoted strings are JSON5, not JSON; use double quotes.: JavaScript object literals, JSON5 and JSONC all tolerate quoting that RFC 8259 forbids. Nothing is emitted until the input is strict JSON, because compact garbage is harder to debug than pretty garbage.
Unexpected 'r' at line 1, column 2 — probable cause: property names must be double-quoted.: Bare keys are legal in YAML and in JavaScript source, never in JSON. Quote every property name and re-run.
Unexpected end of input at line 1, column 14 — probable cause: the document is incomplete or truncated.: An array or object opened and never closed — typically a clipped terminal buffer, a size-capped log field or a partial download. Recover the missing tail; a minified fragment is still a fragment.
This tool streams up to 50MB; beyond that, try the CLI: jq -c . file.json: The page declines the whole input rather than working on a slice, and your paste stays in the pane. At that scale you are minifying a dataset — jq streams it on your machine, just as privately.

FAQ

Does minifying JSON ever change the data?

Not here. Only whitespace between tokens is removed: string contents, key order, escape spellings and every digit ride through byte-for-byte, and the build re-runs each printed example against the engine to hold that promise.

Should I minify, gzip, or both?

For anything crossing the network, compression does the heavy lifting — the measurements above put the gzipped difference near 12%. Minify when a consumer counts raw bytes: inline JSON in HTML, environment variables, storage quotas. Both together is routine.

Why did my input come back the same size?

It was already minified — no whitespace sat between the tokens, so the honest report is a zero-byte saving. Squeezing further would mean rewriting escapes or number spellings — ruled out by design.

Are spaces or line breaks inside strings safe to minify?

Yes. Whitespace is only insignificant between tokens; inside a string literal it is data, and the third example proves it with multi-space runs and an embedded \n escape arriving unchanged.

Keyboard shortcuts

⌘/Ctrl + Enter: Minify now — required past 2 MB, re-runs the current input in any band.
⌘/Ctrl + S: Download the minified output as .json — overriding the browser's save-page shortcut here, per the help overlay note.
⌘/Ctrl + C: With focus in the tool and nothing selected, copies the whole output; a real selection copies itself, as usual.
⌘/Ctrl + Shift + C: Copy the full minified output regardless of selection.
t: Switch theme (idle while typing in a field or during IME composition).
? or ⌘/Ctrl + /: Open the shortcut overlay, where browser-conflict notes live.
Esc: Dismiss the topmost dialog — it never clears your input.

Nothing you paste here leaves this tab. State only ever travels in links you explicitly create.

RFC 8259 — JSON, §2: insignificant whitespace · ECMA-404 — The JSON Data Interchange Standard · MDN — JSON.parse()

Last reviewed: 2026-07-29