JSON Minifier
Strip whitespace from JSON and see the exact byte savings. Parses before minifying, so invalid input is located rather than mangled.
JSON
Minified
Paste valid JSON to see the minified output.
Minification runs in your browser — the payload is parsed and re-serialised locally, never uploaded. Byte counts are UTF-8, matching what actually goes over the wire.
About the JSON Minifier
Strip every unnecessary byte from a JSON document and see exactly what you saved. Whitespace between tokens carries no meaning in JSON, so removing it produces a smaller payload that parses to precisely the same value.
The minifier works by parsing and re-serialising rather than by deleting whitespace with a regular expression. That matters: a naive strip corrupts any string that legitimately contains spaces or newlines, and quietly accepts input that was never valid JSON in the first place. Parsing first means invalid input is reported with a line and column instead of producing a broken result.
Be realistic about the gain. Minifying typically removes 10–30% of a formatted document, but almost every HTTP response is already gzip- or brotli-compressed, and compression eats repeated indentation for very nearly free. The measurable wins are elsewhere: payloads embedded in HTML, values stored in a database column or a cache, config checked into a repository, and anything counted against a size limit before compression applies.
- Parses before minifying, so invalid JSON is reported rather than mangled
- Byte counts in UTF-8, matching what actually travels over the wire
- Savings shown in bytes and percent
- Optional key sorting, which makes two documents diff cleanly
- Structure summary: key count, array count and nesting depth
How to use it
- Paste your JSON into the left pane.
- Read the minified output on the right — it updates as you type.
- Tick Sort keys if you are going to compare this against another document; ordering object keys makes the diff meaningful.
- Check the savings line to see whether minifying is actually worth it for your case.
- Copy the result.
Real-world use cases
Backend & API developers
Minify a fixture before checking it into a test suite, so the file under version control is compact and diffs cleanly instead of carrying pretty-printed noise nobody asked for.
Frontend developers
Shrink a JSON config or translation file embedded directly in an HTML page or a script tag, where gzip has not run yet by the time the browser parses it.
DevOps & platform engineers
Compact a JSON value going into an environment variable, a Kubernetes ConfigMap or a cache entry, where every byte counts against a real size limit rather than a bandwidth budget compression already handles.
QA & performance engineers
Check whether minifying a payload is actually worth doing before recommending it in a review — the savings line makes that a five-second decision instead of a guess.
AI & data engineers
Compact JSON records before pasting them into a prompt, where every whitespace character is billed as a token exactly like a visible one.
Examples
A formatted object
{
"id": "usr_8f2b",
"active": true,
"roles": ["admin", "billing"]
}{"id":"usr_8f2b","active":true,"roles":["admin","billing"]}84 bytes down to 59 — about 30%. All of it was indentation and the spaces after colons and commas.
Whitespace inside strings is preserved
{
"note": "line one\nline two",
"name": "Ada Lovelace"
}{"note":"line one\nline two","name":"Ada Lovelace"}The escaped newline and the double space inside the strings are data, not formatting, and survive untouched. This is exactly what a regex-based minifier gets wrong.
Sorted keys
{"name":"Ada","active":true,"id":7}{"active":true,"id":7,"name":"Ada"}Object key order is not significant in JSON, so sorting is safe and makes two documents comparable. Array order is left alone — that is data.
Invalid input is reported, not minified
{
"name": "Ada",
}Unexpected } — trailing comma before it (line 3, column 1)
A trailing comma is valid in JavaScript and invalid in JSON. Parsing first is what lets the error be located instead of silently producing garbage.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Unexpected token } in JSON | A trailing comma after the last property or array element. Legal in JavaScript object literals, forbidden in JSON. | Delete the comma. If you need trailing commas in a config file, use JSON5 or JSONC and convert before shipping. |
| Unexpected token ' in JSON | Single-quoted strings or unquoted keys — a JavaScript object literal pasted in place of JSON. | JSON requires double quotes on both keys and string values. Nothing else is accepted. |
| Minified output is barely smaller than the input | The document is mostly data rather than structure — long string values, or already compact. | Expected, and fine. If size is the real problem, compression or trimming unused fields will do far more than minifying. |
| Numbers change after minifying | JSON numbers are parsed as IEEE 754 doubles. An integer beyond 2^53, or a high-precision decimal, cannot round-trip exactly. | Send such values as strings. This affects any JSON parser, not just this tool — it is a property of the format. |
| Duplicate keys disappear | The document had the same key twice. Parsing keeps only the last occurrence, per the standard behaviour of every mainstream parser. | Duplicate keys are ambiguous by design. Fix the producer — the data was already being interpreted inconsistently. |
Frequently asked questions
›Is my JSON uploaded anywhere?
No. Parsing, minifying and byte counting all happen in your browser. API responses, tokens and customer data in the payload never leave the page, and nothing is stored or logged.
›Does minifying change the data?
No. The document is parsed to a value and re-serialised, so the result parses to exactly the same value. Only whitespace between tokens is removed — whitespace inside string values is data and is preserved. The one thing that can shift is numeric precision, and that is a property of JSON itself.
›Is minifying JSON worth it if I already use gzip?
Usually not, for HTTP responses. Compression handles repeated indentation extremely efficiently, so minifying on top of gzip often saves only a few percent. It is worth it where compression does not apply: JSON embedded in HTML, stored in a database column or cache, held in localStorage, or measured against a payload limit before compression.
›Why not just strip whitespace with a regular expression?
Because a regex cannot tell whitespace inside a string from whitespace between tokens. A pattern that removes newlines will corrupt any string containing one, and will happily process input that was never valid JSON. Parsing is both safer and the only way to report where an error actually is.
›Is it safe to sort object keys?
Yes. JSON object members are unordered by specification, so reordering them does not change the value. It is genuinely useful when diffing two documents that were produced by different serialisers. Array elements are never reordered — order in an array is data.
›How large a document can it handle?
It is limited by your browser's memory rather than any cap here, and multi-megabyte documents are fine on a desktop machine. Very large files may make the live preview feel sluggish, because the result is recomputed on each keystroke.
›Does minifying reduce token count for an LLM prompt?
Yes, and unlike an HTTP response it is not something gzip will do for you before billing — a tokenizer sees the whitespace you pasted, not a compressed version of it. Stripping indentation from a JSON block before it goes into a prompt is one of the few genuinely free ways to cut tokens without changing the data.
›Is minified JSON still valid JSON?
Yes. Whitespace between tokens is entirely optional in the JSON grammar, so removing it produces a document that parses to the identical value. Any conforming JSON parser accepts minified output exactly as it accepts the formatted original.
Last updated