Minify JSON to the smallest valid form or pretty-print it with 2 spaces, 4 spaces or tabs. Optional key sorting, live byte-saving figure, runs entirely in your browser.
Strip every byte that does not change the data. Paste JSON to remove all optional whitespace, or switch to beautify to lay it back out with the indent you prefer. Key sorting makes two documents comparable, and the byte counter shows what the minification actually bought you.
JSON's grammar allows spaces, tabs and newlines between any two tokens, and none of them carry meaning. Minifying is the act of dropping every one of those optional characters: {"a": 1, "b": 2} becomes {"a":1,"b":2}. The parsed value is byte-for-byte identical in memory, which is why this operation is always safe to apply to a payload before sending it.
What minifying does not do is compress the data. Key names, string contents and numeric precision are all preserved exactly. If your document is large because it repeats the same twenty field names across ten thousand records, minification will shave the indentation but leave the repetition untouched — that is a job for gzip or a different schema.
On a typical pretty-printed API response, whitespace accounts for somewhere between 10% and 30% of the raw size. That sounds worthwhile until you remember that almost every HTTP response is already gzip- or brotli-compressed in transit, and compression algorithms handle runs of spaces extremely well. After gzip, the difference between minified and formatted JSON is often under 2%.
Minification still earns its place in three situations: data embedded directly into an HTML page or a JavaScript bundle, where it is not separately compressed; storage in a database column or a cache, where the raw string is what occupies space; and anywhere you are counting characters against a hard limit, such as a URL parameter or a message field with a fixed cap.
JSON objects are officially unordered, but every serialiser writes keys in some concrete order, and two systems rarely choose the same one. That makes a plain text diff of two logically identical documents unreadable.
Sorting keys recursively before output gives both documents the same canonical shape, so a line diff finally shows only the real changes. It is the same trick behind reproducible builds and content-addressed caching. Do keep in mind that sorting changes the byte output, so a sorted document is no longer identical to what the source system produced — use it for comparison, not for round-tripping signatures.