Strip whitespace from JSON to shrink API payloads. Free, private, runs in your browser.
100% private — your files never leave your browser. All processing happens locally on your device.
Pretty-printed JSON is great for humans reading it in an editor. For machine-to-machine transport — API responses, message queues, log pipelines — every byte of indentation and newline whitespace costs bandwidth, memory, and parse time. Minifying a large JSON payload before sending it over the wire typically shaves 15-30% off the byte count. On a busy API handling millions of requests a day, that's meaningful bandwidth and CDN-cost savings, and on mobile clients it's a measurable first-paint improvement.
It removes every whitespace character — spaces, tabs, newlines — that sits between JSON tokens. `{ "a": 1 }` becomes `{"a":1}`. The parsed meaning is identical because JSON whitespace between tokens is semantically insignificant. Whitespace inside a string value is preserved — `"hello world"` stays `"hello world"`. Key order is preserved as written; keys and values are left untouched. Only the whitespace is stripped.
Minification is not the same as compression. Gzip (or Brotli, or any compression layer your CDN applies) removes redundancy across the entire payload by building a dictionary — it dramatically shrinks both pretty and minified JSON, often getting the pretty version down to within a few percent of the minified version. So why minify at all? Because not every hop is compressed — in-memory message queues, client-side `localStorage`, diff-friendly git-tracked config files — and those cases still benefit from raw-byte reduction. And minification composes with compression: a minified payload compresses to an even smaller gzipped size than a pretty one.
The tool parses your input with `JSON.parse` before emitting anything. If your input has a syntax error, you see the error message and no minified output — which means you can paste a suspicious payload from an API response and use the minifier as a cheap validator. No error means the JSON is valid. If it passes validation, the tool re-serializes with `JSON.stringify` using no indent argument, producing the canonical minified form.
Pretty-printed JSON with 2-space indentation typically shrinks 15-30% after minification. Deeply nested documents with lots of whitespace see the biggest savings.
Yes. The minifier parses your input first to validate it, then re-serializes without whitespace. If your input had a syntax error, the tool tells you what and where, so you can fix it before minifying.
No. Minification only removes whitespace between tokens. Keys, values, types, and structure are identical — the byte-count shrinks but the parsed output is the same.
For machine-to-machine APIs, yes — smaller payloads mean lower bandwidth costs and faster parsing. If humans need to read the output (e.g., developer debugging), keep it pretty. Either way, gzip on the wire gives you most of the savings for free.