JSON Minifier — Compress JSON Online

Shrink JSON payloads to save bandwidth

Every byte in a JSON response costs something. On mobile networks, it costs the user time. On high-traffic APIs, it costs the operator bandwidth. In storage, it costs space on disk and in backups. Minifying JSON removes every byte that the parser does not strictly need — whitespace between tokens, new lines between elements, indentation inside objects — and produces the smallest valid JSON document that still represents the same data.

For a typical pretty-printed API response with two-space indentation, minifying removes between 20% and 40% of the bytes. The exact savings depend on how deeply nested the data is and how descriptive your key names are. A flat object with long string values saves less than a deeply-nested object with short string values, because the latter has more whitespace per byte of data.

Minifying is reversible and lossless

Minification only removes characters that the JSON spec treats as insignificant whitespace. The structure and the values are preserved exactly. Any JSON parser will read the minified file the same way as the original — that is the whole point of treating whitespace as insignificant. You can minify and beautify the same document back and forth as many times as you want without losing any data.

When minifying helps, when it doesn't

Minifying helps when the JSON is shipped over a network. Every byte counts on mobile connections and on high-traffic APIs, so stripping whitespace is a free win. Minifying also helps when JSON is stored in a text column in a database — smaller rows mean faster scans and smaller backups.

Minifying does not help when the JSON is gzipped in transit. In fact, minified JSON sometimes compresses slightly worse than beautified JSON under gzip, because the beautified form has more repeated whitespace runs that gzip can collapse. For HTTP traffic, the right move is usually minify first, then let the server gzip the response — that gives you both small storage and small wire size.

Minifying does not shorten key names

Some developers wonder if they should also shorten their key names (e.g. firstName to fn) to save even more space. That is almost never worth it. Long key names hurt readability in your codebase and only help if the data is mostly keys with short values. For data-heavy payloads — long strings, big arrays — the values dominate and shortening keys has almost no effect. Gzip already compresses repeated key names very well, so the on-the-wire savings of shortened keys is usually negligible.