JSON Minifier (Compress to One Line)
Collapse multi-line JSON into a single compact line, with syntax still validated and the before-and-after byte size visible, for request bodies, log lines and message payloads.
Indented JSON is good for reading and bad for transport. The spaces and line breaks around the structure mean nothing to a parser, yet they add real bytes to request bodies, log files and message queues. This tool merges the document into one line, keeping only what the grammar requires; characters inside string literals are not touched at all, and the status bar lets you read the size before and after in the same place.
The work happens in the browser: parse, then re-serialize without indentation. Nothing is posted to a server, and there is no proxy or access log in between. That is the precondition for pasting sample payloads that contain phone numbers, order IDs or internal service hostnames. The page also runs offline — the implementation is compiled into the front-end bundle and needs no API.
What minifying does, and what it does not
The implementation parses with JSON.parse and then serializes without an indent argument, so what disappears is all whitespace outside the syntax: newlines around objects and arrays, spaces after commas, whitespace on either side of a colon. Inside strings nothing changes. Two consecutive spaces in "a b" survive minification, and a line break only exists there if it was written as \n. It is equally important to note that this is not plain text substitution: numeric notation is normalized (1.0 becomes 1, 1e3 becomes 1000), escapes such as \u00e9 are decoded to their characters, and duplicate keys within one object keep only the last value, since the parser overwrites earlier ones.
How many bytes you actually save
The saving depends on the original indentation and the nesting depth. With the usual two-space indentation, expect roughly 10 to 30 percent; deep nesting combined with long key names does better, while input that was already compact shrinks by almost nothing. The status bar reports the true UTF-8 byte size of the current content, switching to KB above 1024 bytes, so checking it once before and once after gives you the exact gain. One counter-intuitive detail: if the source document stores non-ASCII characters as \uXXXX escapes, decoding them to literal characters makes it smaller, not bigger — an escape costs 6 ASCII bytes where the UTF-8 encoding needs 3 for the same character, and 4-byte characters such as emoji shrink from 12 bytes as a surrogate pair to 4.
When not to minify
Minifying trades away readability, so it has no place anywhere a human needs to read the file: config committed to a repository, a data listing someone has to check by hand, examples embedded in API documentation. Also note that minification requires a successful parse — a single syntax error fails the entire operation, and the status bar reports the error line and snippet instead of a result, so the document has to be fixed (or handed to the repair tool) first. If you only want to remove excess spaces while keeping the multi-line structure, running the formatter is the better fit.
Frequently asked questions
- Is minified JSON semantically the same as the original?
- Yes. Line breaks and indentation are not data; a parser only sees the structure, so both versions parse to the same object. Two things can change without affecting meaning: numeric notation is normalized, so 1.0 and 1 are the same number, and duplicate keys resolve to the later value, which is what the standard prescribes.
- Are spaces inside strings removed?
- No. Minification targets structural whitespace outside string literals; spaces, tabs and \n escapes inside double quotes are preserved exactly. A string containing three consecutive spaces still contains three after minifying. That is the fundamental difference from a regex that strips blank space globally, which silently corrupts string content.
- Why did the file get bigger instead of smaller?
- If the source was already compact there was almost nothing to remove — only the occasional space after a comma. A byte counter can also disagree with your file manager when the original was saved in a different encoding: the tool measures UTF-8, so a document measured in a 2-byte-per-character encoding may appear to grow. That is a difference in how the size is measured, not inflation introduced by minifying.
- Can minifying strip comments and trailing commas along the way?
- No. Comments and trailing commas are not part of the JSON grammar, so parsing fails outright and minification never runs. Text like that has to go through the repair tool first: it removes // and /* */ comments and deletes commas that sit immediately before a closing brace or bracket, after which the result can be minified.