JSON Minifier
Max 512 KB · Minifies automatically as you type
Processed entirely in your browser — nothing is sent to a server.
What is a JSON minifier?
JSON’s whitespace — the newlines and indentation that make a nested object readable — carries no meaning to anything that parses it. A JSON minifier strips all of that non-significant whitespace out, collapsing a formatted document down to the smallest valid representation of the exact same data: same keys, same values, same structure, just none of the characters that existed purely for a human reader. It’s the direct complement to a JSON formatter, which does the opposite — re-indenting minified JSON into a readable form. The two operations are fully reversible: minifying loses nothing a formatter can’t restore, because neither one ever touches the actual data, only how it’s spaced out.
Why minify JSON
The main reason is size. A deeply nested config or API response can easily be 20-30% smaller minified than formatted, purely from removed whitespace — and that difference compounds anywhere JSON is transmitted or stored repeatedly: an API response served to thousands of clients, a config file fetched on every page load, or a bulk export written to disk. None of that whitespace helps a program read the file faster; it only helps a person editing it by hand. The common pattern is to keep a source file formatted (for version control diffs and code review) and minify it as a build or deploy step, so the readable version and the shipped version are different artifacts serving different audiences.
How it works
Paste JSON into the input field; the minified result appears on the right as you type, debounced slightly so it doesn’t reprocess on every keystroke. Parsing uses the browser’s built-in JSON.parse, exactly the same step the JSON Formatter uses — the only difference is what happens after a successful parse: this tool calls JSON.stringify with no indentation argument at all, producing the shortest valid serialization, while the formatter calls it with a 2-space indent for readability. Because both tools share that identical parse step, any input that’s valid on one is valid on the other, and the error messages you’ll see for broken input are the same too. If JSON.parse throws, the tool shows the error message along with the line and column where parsing failed, rather than a blank or partial output. Nothing here touches a server — the 512 KB input cap exists only so very large documents stay responsive to re-process on every keystroke in a browser tab, not because of any transmission limit.
Examples
- Shrinking an API response before embedding it in a script tag or a data attribute, where every extra byte of indentation ships to every visitor.
- Preparing a config or fixture file for production, where the formatting that made it easy to edit in a code review is pure dead weight once it's deployed.
- Minifying scraped or exported JSON before storing it — a database export or a log line is often pretty-printed for a human to skim once, then minified to save real storage space in bulk.
Frequently asked questions
Is my JSON sent to a server?
JSON.parse/JSON.stringify. No data leaves your device.