JSON minifier

Last updated June 2026 · Maintained by the JSONNeat author

What minifying actually does

The minifier calls JSON.parse on what you pasted, then re-serializes withJSON.stringify and no indent argument. That's the one-liner; anything else you read about JSON minification is variations on that pattern. The output is byte-identical to what your backend would produce by default.

Nothing inside string values is touched — a space inside "hello world" stays as it is. Numbers are normalised to their shortest round-trippable form, so 1.0 may come out as1, but the parsed value is unchanged.

How much you actually save

The headline figure of "20–60% smaller" depends entirely on how the source was written. Here is a worked example of the same five-record dataset at three indentation styles:

• Two-space indented: 412 bytes → 188 bytes minified (54% reduction)
• Four-space indented: 562 bytes → 188 bytes (67% reduction)
• Already single-line, but with spaces after colons and commas: 224 bytes → 188 bytes (16% reduction)

The smaller the keys and the deeper the nesting, the more dramatic the absolute saving. A 1 MB JSON file that was hand-formatted with four-space indents commonly minifies to under 400 KB.

Minification vs. gzip — when each matters

The most common pushback on minification is that gzip already removes repeated whitespace very efficiently. That is true. A response that goes from 1 MB to 400 KB minified will only shrink to roughly 90 KB once gzipped — and the pretty-printed version gzips to maybe 95 KB. The marginal wire saving is small.

Where minification still wins:

• No compression on the link. Internal service-to-service calls, message queues, and many gRPC-over-JSON setups don't bother with gzip because CPU is more expensive than bandwidth at small payload sizes. Here the minified bytes are exactly what's transferred.
• Storage and logs. A document database, S3 bucket, or log aggregator that stores raw JSON text pays for every byte. Minified JSON compresses better at rest too, because there is less redundant whitespace for the compression dictionary to handle.
• Memory and parse time. A 1 MB string is faster to parse than a 2.5 MB string even though the parsed value is identical. The cost is small per request but compounds when a service handles thousands per second.
• Embedded JSON. When JSON is a value inside another JSON document (a webhook payload, a configuration field, a database column), every extra byte of indentation in the inner document gets escaped and re-encoded in the outer document, multiplying the cost.

Worked example

Input (89 bytes including indentation):

{
  "user": {
    "name": "Ada",
    "skills": ["math", "computing"]
  }
}

Minified output (50 bytes):

{"user":{"name":"Ada","skills":["math","computing"]}}

That is a 44% reduction with no information loss. Pasting the minified version back into a JSON formatter will reproduce the original document exactly (give or take which indent size you choose).

When you should not minify

• Anything a human will read. Configuration files, fixture data in source control, and error responses in development are easier to debug pretty-printed. Reserve minification for the wire.
• Git-tracked files. Minified JSON produces enormous, unreviewable diffs. Keep the indented version in the repo; minify at build time if you ship the file to a CDN.
• Snippets in documentation. A minified example in a README defeats the purpose of the example.

Common errors and how to fix them

• "Unexpected token" at the start of the document. The minifier validates as it goes — if it rejects your input, the document is not valid JSON. Run our JSON validator first to find the exact line and column.
• Output is the same size as the input. Your input is already minified, or contains mostly string content (long descriptions, base64 blobs) where there is no whitespace to remove.
• Numbers look different after minifying. 1.0 becomes 1,1e2 becomes 100, and very long decimals may be re-rendered in scientific notation. The numeric value is unchanged — only the textual form.
• Comments disappeared. JSON does not support comments, and the minifier (correctly) won't accept them either. If you have comments in your source, you have JSON5 or JSONC, not JSON. Strip them with a JSONC-aware preprocessor before minifying.

How JSONNeat's minifier works under the hood

The minifier calls the browser's native JSON.parse on your input, then immediatelyJSON.stringifys the result with no second or third argument. This is the same approach used by virtually every production JSON minifier — the spec-compliant parsers are the same code that runs in V8, SpiderMonkey and JavaScriptCore, so the output is byte-identical to what your Node.js or browser backend would produce. Nothing exotic, no regex hackery, no whitespace-stripping heuristics that could break edge cases.

Privacy

The minifier runs entirely client-side. Your JSON is never uploaded, logged or cached on JSONNeat's servers. That makes it safe for minifying internal configuration files, JWT payloads, or anything else you would not want to paste into a third-party tool that touches a remote backend.