JSON Minifier

How it works

• The JSON is parsed and re-serialised, so the output is always valid and the data is unchanged. Whitespace between tokens is dropped; whitespace inside string values is preserved, because that is data.
• The byte saving is measured in UTF-8 bytes rather than characters, which is what actually matters for transfer size when the content is not pure ASCII.
• Escape mode produces the form you need to embed JSON inside another string — every quote backslash-escaped — and unescape mode reverses it.
• When parsing fails, the error reports the line and column and shows the surrounding text, because "unexpected token" on its own is not useful on a large document.

Use cases

What minifying JSON does and does not save

Minifying removes the whitespace between tokens: the indentation, the newlines, and the space after each colon and comma. It never touches whitespace inside a string value, because that is data rather than formatting. The output parses to an object identical to the input, which is what makes the operation safe to apply automatically.

The saving is real but smaller than it looks once compression is involved. Indented JSON typically shrinks 10 to 30 percent when minified, and more when it is deeply nested, because indentation accumulates with depth. However, gzip and brotli are extremely good at compressing repeated whitespace, so if the content is served compressed — which it should be — the additional saving on the wire is modest. Where minification still pays clearly is in storage, in fields with a hard size limit, and in anything measured uncompressed such as a log line or a message queue payload.

The byte figure above is measured in UTF-8 bytes, not characters, which matters for non-English content: an accented character costs two bytes and an emoji four, so a character count would understate the true size.

Escaping JSON to live inside a string

Putting JSON inside a JSON string is a routine task that goes wrong constantly, because every double quote in the inner document has to be escaped, and so does every backslash, newline and control character. Doing it by hand on anything non-trivial produces a document that parses but has lost a layer of escaping somewhere in the middle, which then fails much later and far from the cause.

This comes up more often than it should: a webhook payload stored in a text column, a JSON config passed through an environment variable, a fixture embedded in a test file, a value in a YAML field. In each case the inner document needs to survive being read as a string first and parsed second.

The escape mode produces exactly that form, and the unescape mode reverses it, accepting input with or without the surrounding quotes. If a document has been escaped twice — which happens when it passes through two such layers — run unescape twice.

Reading a JSON syntax error

Most JSON parse failures are one of four mistakes. A trailing comma after the last element of an object or array, which JavaScript tolerates and JSON does not. Single quotes instead of double, usually from pasting a JavaScript object literal. An unquoted key, same cause. And an unescaped newline inside a string value, usually from a copy-paste out of a terminal.

The error message on its own is rarely enough on a large document, because "unexpected token" tells you where the parser gave up rather than where the mistake is — and those are often different places. A missing closing brace is reported at the end of the file. That is why the output above gives the line, the column, and the surrounding text: the context is usually what identifies the actual problem.

If a document fails to parse and nothing looks wrong, check the very first character. A byte order mark left by a Windows editor is invisible and will reject an otherwise perfect file. The Unicode Character Inspector will show it.

FAQ