JSON Minifier
Strip whitespace from JSON to make it as small as possible, with optional key sorting and a byte-count comparison showing what you saved.
This is not a text operation, and that has consequences
You might expect a minifier to walk the document and delete the whitespace between tokens. This one does something else: it parses the text into a value, then prints that value back out with no spacing. The result is always valid JSON meaning the same thing — the worked example below goes from 132 bytes to 69, a saving of 47.7%, with the value unchanged.
But "the same thing" is a claim about the value, not about the text. Four things that look like part of your document do not survive the trip, and none of them is whitespace.
Keys that look like integers are reordered
| In | Out | |
|---|---|---|
{"2":"b","1":"a"} | {"1":"a","2":"b"} | numeric keys sort ascending |
{"10":"x","9":"y","2":"z"} | {"2":"z","9":"y","10":"x"} | even across digit counts |
{"b":1,"a":2} | {"b":1,"a":2} | ordinary keys keep insertion order |
{"b":1,"2":"x","a":3} | {"2":"x","b":1,"a":3} | numeric first, then the rest as written |
Objects keep string keys in the order you wrote them but always list integer-like keys first, in ascending numeric order — whether or not you asked for sorted keys, and whatever order the file had. Note that it is not alphabetical either: sorted as text, "10" would come before "9".
Duplicate keys collapse
| In | Out | |
|---|---|---|
{"a":1,"a":2} | {"a":2} | the last value wins |
{"a":1,"b":2,"a":3} | {"a":3,"b":2} | last value, first position |
JSON permits a key to appear twice and the parser keeps the last value. The second example is the one to look at: the last value ends up at the first position, a combination that appeared nowhere in the input. A document that recorded something twice loses that fact with no warning.
Numbers and escapes are re-printed from the value
| In | Out | |
|---|---|---|
{"a":1.0} | {"a":1} | a trailing zero is not a value |
{"a":1.50} | {"a":1.5} | nor a second one |
{"a":1e3} | {"a":1000} | exponents are expanded |
{"a":0.5e1} | {"a":5} | and evaluated |
{"a":1E+2} | {"a":100} | whatever the spelling |
{"a":-0} | {"a":0} | negative zero is not preserved |
Every one of those is the same number, and none of them is the same text. The document had a chosen notation; the value does not carry it. If those digits were a version, a price written to two decimal places, or an identifier that happens to be numeric, the notation was the information and it is gone.
Escapes get the same treatment, and here the rewriting is almost always an improvement — shorter, and easier to read:
| In | Out | |
|---|---|---|
{"a":"\u00e9"} | {"a":"é"} | a letter that needs no escape |
{"a":"\u0041"} | {"a":"A"} | nor does an ASCII one |
{"a":"\/"} | {"a":"/"} | the optional slash escape is dropped |
{"a":"\u2028"} | {"a":"␞"} | the line separator comes out raw |
The last row is the one worth remembering. U+2028, the line separator, comes out as a raw character rather than an escape. That is perfectly legal JSON — and it was historically a syntax error the moment somebody pasted that JSON straight into a JavaScript source file, because the language treated it as a line break in the middle of a string.
What is preserved exactly
| In | Out | |
|---|---|---|
{"a":" spaced "} | {"a":" spaced "} | spaces inside a string are data |
{"a":"line\nbreak"} | {"a":"line\nbreak"} | so are newlines |
{"a":[1,2,3]} | {"a":[1,2,3]} | arrays keep their order |
{"a":{"b":{"c":1}}} | {"a":{"b":{"c":1}}} | nesting is untouched |
Everything inside a string, to the character. Whitespace between quotes is data rather than formatting, and this is precisely where a naive whitespace-stripping minifier would corrupt your document and a parse-and-print one cannot. Nesting, array order and the order of ordinary keys are untouched.
So the trade favours this approach, and it is worth stating plainly: what you get is a minifier that can never produce invalid JSON and can never damage a string. What you give up is byte-level fidelity to notation you may not have realised you were relying on. The value is identical either way — only the spelling is not.
How to use
- Paste your JSON into the input box.
- Minify to strip every byte of optional whitespace.
- Optionally sort keys so later diffs show only real changes.
- Check the before-and-after byte count to see what you actually saved.
- Copy the result or download it as a file.
Frequently asked questions
How much smaller does minifying make JSON?
Typically 10 to 30 per cent, depending on how deeply nested and heavily indented the original was. Deeply indented data with short values saves most, since the indentation can genuinely outweigh the content it surrounds.
Is it worth minifying if the server already compresses responses?
Much less than people assume. Gzip and Brotli compress repeated whitespace almost to nothing, so minified and formatted JSON often differ by only a few per cent once compressed. Minify for storage, for embedded payloads, and for anything served uncompressed — but do not expect a dramatic gain over the wire.
Does minifying change the data in any way?
No. Only whitespace between tokens is removed, and JSON attaches no meaning to that. Whitespace inside a string value is preserved exactly, because there it is data rather than formatting, and stripping it would corrupt the document.
Why would I sort the keys?
For stable comparisons. Two documents holding identical data in different key order produce a completely different diff, which makes reviewing changes painful and hides the real edit among the noise. Sorting canonicalises the output so a diff shows only genuine changes.
Should I minify configuration files?
No. Configuration is read and edited by people, and the bytes saved are irrelevant against the readability lost. Minify data that machines exchange between themselves, not files that humans have to maintain.
Does my data get uploaded anywhere?
No. The parsing and minifying happen entirely in your browser, so nothing is sent to a server. That matters for JSON containing API responses, access tokens or customer records — exactly the material that should never be pasted into an unfamiliar website.
What about JSON Lines?
A different format for a related problem: one JSON document per line, with no enclosing array and no commas between records. It suits streaming and log files, because a reader can process one record at a time without parsing the whole file, and appending a record needs no rewriting of a closing bracket.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.