Minifying matters wherever JSON crosses a wire or gets embedded in something else. A pretty printed 200 kilobyte API fixture is routinely 30 to 50 percent whitespace, and that whitespace is paid for on every request, in every bundle and in every row of a database column holding a serialised blob.
The work happens in the tab you are reading this in, which is the point of being able to minify json online rather than posting a file to a service. The document is parsed and re serialised locally, so an export containing customer records is never transmitted anywhere. There is no upload, no queue and no daily cap.
When minifying JSON is worth doing
Anywhere the document is read by code rather than by a person. An HTTP response body, a config file baked into a build, a message on a queue and a value stored in a text column all benefit, and none of them lose anything you can see. The goal in each case is to reduce json payload size without altering a single value.
It is the wrong move anywhere a human has to read or review the file. A minified file in version control produces a diff of one changed line every time a single value changes, which destroys the history you keep a repository for.
- Trimming API responses and fixtures before they ship.
- Embedding JSON in an HTML attribute or a script tag.
- Storing a blob in a database column where every byte is charged.
- Preparing a payload for a queue, a webhook or a log line.
- Cutting a large seed file down before it enters a bundle.
How much smaller does JSON actually get?
The saving depends entirely on the shape of the document. A deeply nested object indented with four spaces can lose more than half its bytes, because every one of those lines carries leading whitespace. A flat array of short numbers may lose almost nothing, since there was little formatting to remove.
Typical results sit between 15 and 45 percent for hand written config and between 30 and 60 percent for machine generated exports formatted with a pretty printer. Run the JSON minifier and the stats panel reports the real number for your file rather than a promise, so you can decide whether it was worth it before you compress json file output any further.
Minification is not compression
Removing whitespace and applying gzip or brotli are different operations that stack. Compression already handles repeated indentation well, so minifying a document that will also be gzipped often saves only a few percent more over the wire.
Where minification wins outright is everywhere compression is absent: an inline script tag, a database column, a log line, a message body on a queue that stores raw bytes, or a runtime that parses the text before any transport layer sees it. Smaller input is also marginally faster to parse.
Treat this JSON minifier as the step that removes bytes the format never needed, and treat transport compression as the separate step that removes redundancy across the bytes that remain.
What a safe JSON minifier will never change
Whitespace inside a string is data. A value of "hello world" with two spaces has to survive intact, which is why naive attempts to remove whitespace from json with a regular expression corrupt files: they strip spaces without knowing whether those spaces are inside quotes.
This tool parses the document into real values and re serialises them, so strings, key order and numeric values all come through untouched. Nothing is guessed, and a document that will not parse is reported as an error rather than being mangled quietly.
One caveat is worth stating. Numbers are re serialised by the JavaScript engine, so an integer larger than 2 to the power of 53 loses precision, and a value written as 1.50 comes back as 1.5. Both are correct JSON, but if you carry large identifiers, keep them as strings.
The escape option and non ASCII text
By default the output keeps characters as they are written, so accented letters, Chinese characters and emoji stay readable in the minified result. That is the smallest and most portable choice when the file is served as UTF-8.
The escape option rewrites every character above the ASCII range as a \u sequence instead. The file grows, but it becomes pure ASCII, which is what you want when a document has to pass through a system with an unreliable encoding path such as an old logging pipeline or a database connection with a mismatched charset.
Sorting keys while you minify
Object key order carries no meaning in JSON, but tooling often depends on it anyway. Sorting keys alphabetically makes two exports of the same data byte identical, which turns a checksum comparison into a reliable equality test and makes caching predictable.
Array order is never touched, because array order is meaningful. Only object members are reordered, and only when you ask the JSON minifier to do it.
| Document | Formatting | Usual saving |
|---|---|---|
| Hand written config | 2 space indent | 15 to 30 percent |
| API response fixture | 4 space indent | 30 to 50 percent |
| Deeply nested export | 4 space indent | 40 to 60 percent |
| Flat array of numbers | single line already | close to nothing |
How to minify JSON
- 1
Add your JSON
Paste the document into the input box or drop a .json file onto the drop area. It is read on your own device.
- 2
Choose the options
Decide whether to sort object keys and whether to escape non ASCII characters as \u sequences. Both default to off.
- 3
Minify the document
Press minify. The JSON minifier stops on invalid input with the line and column where parsing failed rather than producing a broken file.
- 4
Check the saving and download
Read the before and after byte counts, then copy the result or download it as a .min.json file.
Related tools worth bookmarking
Sources and further reading
- RFC 8259: The JSON Data Interchange FormatThe current JSON standard, which defines exactly where whitespace is insignificant and may be removed.rfc-editor.org
- json.org: the JSON grammarThe original grammar diagrams showing every token that whitespace is allowed to sit between.json.org
- MDN: JSON.stringifyDocumentation for the serialiser used here, including how the space argument controls output whitespace.developer.mozilla.org
Frequently asked questions
Common questions about the json minifier.
No. The document is parsed into real values and written back out, so keys, strings and array order are preserved exactly. Only whitespace between tokens is removed, and whitespace inside a string is never touched.
No. Parsing and serialising both run in your browser, so the document never leaves your machine. You can confirm it by opening the network panel of your developer tools and minifying a file while watching for requests.
Usually the extra saving over the wire is small, because compression handles repeated indentation well. Minify anyway when the JSON is embedded in a page, stored in a database column or written to a log, since none of those paths compress it.
Yes. Minification removes nothing but whitespace, so running the result through a JSON formatter restores readable indentation. The two operations are exact inverses apart from number formatting and any key sorting you asked for.
JavaScript parses numbers as doubles, so integers beyond about 9 quadrillion are rounded to the nearest representable value. Snowflake identifiers and similar long numeric keys should be carried as strings in JSON for exactly this reason.