100% local

JSON Minifier

data_object Input
task_alt Output

JSON Minifier

Strip every byte of insignificant whitespace from JSON and see exactly how much you saved. The output parses to the same values as the input.

Minifying JSON removes the spaces, tabs, and line breaks that sit between tokens. Whitespace inside string values is untouched, because it is data rather than formatting. What is left is the shortest byte sequence that still parses to the same structure, which is what you want to store in a cache, put in a database column, or return from an endpoint.

The size counter is the reason to use a minifier interactively rather than in a build step: it tells you whether the saving is worth anything for your particular payload. Deeply nested documents with short values benefit the most, because indentation is a large fraction of their bytes. Flat documents with long string values barely change at all.

How much minification really saves once gzip is involved

Raw minification numbers look impressive and are usually quoted on their own, which is misleading for anything served over HTTP. Almost every server and CDN already applies gzip or brotli, and compressors are extremely good at repeated whitespace. Indentation is the most repetitive content in a pretty printed document, so it is precisely what gzip eliminates for free.

Here is a measurement on a 40 record array of user objects, the shape of a typical list endpoint response. Pretty printed with two space indentation it is 10,562 bytes. Minified it is 6,154 bytes, a 41.7 percent reduction, which is the number a minifier will proudly show you. After gzip, the pretty printed version is 668 bytes and the minified version is 599 bytes. The real saving on the wire is 10.3 percent, not 41.7 percent.

The conclusion is not that minifying is pointless, it is that the payoff depends on where the bytes live. Minify when the size is uncompressed and counted directly: rows in a database column, values in localStorage or Redis, documents you are charged for by the byte, or payloads that must fit a fixed field. For an HTTP response body behind a CDN, enabling compression matters far more than minifying, and doing both buys you about a tenth on top.

Measured sizes for a 40 record array

The same document at each stage, measured with Node and zlib defaults. Reproduce it yourself before trusting any minification claim, including this one.

StageSizeNotes
JSON.stringify(v, null, 2)10,562 BPretty printed baseline with two space indentation.
JSON.stringify(v)6,154 BMinified. 41.7 percent smaller than the baseline.
gzip(pretty)668 BBaseline after gzip. Compression alone beats minification by a wide margin.
gzip(minified)599 BMinified and gzipped. Only 10.3 percent below the gzipped baseline.

Minifying a nested object

Whitespace between tokens disappears. Whitespace inside a string value does not.

Input
{
  "city": "New York",
  "coords": [
    40.71,
    -74.01
  ]
}
Output
{"city":"New York","coords":[40.71,-74.01]}

The two spaces in "New York" survive because they are part of the string. Every other space, newline, and indent is gone.

Common Pitfalls

Minified is not compressed

Minifying removes redundant characters but leaves the result as plain text that a human can still read. It is not gzip, brotli, or a binary format like MessagePack or CBOR. If you need a genuinely small payload, compress after minifying, and expect compression to do most of the work.

Newlines inside string values are preserved, and that is correct

A JSON string containing an escaped newline keeps it, because removing it would change the data. If you expected a multi line string to collapse onto one line, minification is not the tool for that. Rewrite the value itself.

{"note":"line1\nline2"}

Minifying twice gains nothing

Running an already minified document through again returns it unchanged and reports zero savings. There is no second pass of redundancy to remove, because whitespace between tokens is the only thing minification touches.

How to Use

  1. Paste formatted JSON: Drop in an indented document, ideally one you actually ship, so the size numbers are meaningful.
  2. Click Minify: Press the Minify button to remove all unnecessary whitespace.
  3. Check the savings: View the size comparison stats showing original size, minified size, and percentage saved.

Key Features

  • Real-time size comparison with original vs. minified stats
  • Removes all whitespace, newlines, and indentation
  • Preserves all data values: only formatting is removed
  • One-click copy for easy pasting into production code

Use Cases

  • Reducing JSON payload size for faster API responses
  • Optimizing JSON configuration files for production deployment
  • Minimizing localStorage or sessionStorage usage in web apps

Frequently Asked Questions

How much space can I save by minifying?

Between roughly 20 and 60 percent of raw bytes, depending on how deeply nested the document is and how short its values are. On a measured 40 record sample it was 41.7 percent. Over HTTP with gzip enabled the real saving drops to around 10 percent.

Does minifying change my JSON data?

No. Minification only removes whitespace. Your data values remain exactly the same.

Can I minify already minified JSON?

Yes, but there will be no size reduction since the JSON is already compact. The output will be identical to the input.

Does minification affect JSON validity?

No. Minified JSON is fully valid JSON. It is simply more compact and harder for humans to read, but perfectly parseable by any JSON parser.

Should I minify JSON that my server already gzips?

Usually not worth a build step. Gzip removes repeated whitespace very efficiently, so on a measured sample minification only cut a further 10.3 percent after compression. Minify when bytes are counted uncompressed, such as in a database column or localStorage.

Is minified JSON still valid JSON?

Yes. Whitespace between tokens is insignificant in JSON, so removing it produces a document that any conforming parser reads identically. The only cost is readability.

Does minifying lose precision on large numbers?

Minifying goes through the same parse and re-serialize cycle as formatting, so integers beyond 2^53 are rounded. That is a property of parsing JSON numbers as doubles, not of minification itself. Send large IDs as strings if this matters.