Minifier du JSON
JSON Minifier strips all redundant whitespace, indentation, newlines, and JSONC comments from JSON payloads while strictly preserving RFC 8259 syntax integrity. It reports before-and-after byte counts, percentage size reduction, the real gzip wire size measured by your browser, and key-shortening frequency analysis to optimize HTTP payload transfer.
L’interface de cet outil est en anglais.
Le guide ci-dessous n’est disponible qu’en anglais.
How does JSON Minifier work?
In production web applications and microservices, JSON payloads often contain 20% to 55% redundant whitespace introduced by pretty-printers, code formatters, or developer indentation. This dead weight directly inflates network transit latency, consumes egress bandwidth, and slows JSON.parse deserialization times.
The ToolsByUs minification engine performs full lexical tokenization:
- Zero Syntax Corruption: Whitespace within quoted string literals is preserved verbatim, while structural whitespace (spaces around colons, commas, and brackets) is completely stripped.
- Comment Stripping: Tolerates and strips single-line (
//) and multi-line (/* */) comments commonly present in JSONC configuration files. - Real Gzip Measurement: The minified output is compressed with the browser's own
CompressionStream("gzip")encoder, so the reported wire size is measured, not modelled. Browsers without that API fall back to a Shannon-entropy approximation, and the label says which figure you are looking at. - Key-Shortening Analytics: Inspects recurring property names. When long property keys (e.g.
transactionIdentification) repeat across hundreds of array entries, the report calculates exact byte savings achievable by shortening them.
Uncompressed Formatted JSON
{
"status": "ok",
"code": 200
}Example output
{"status":"ok","code":200}What options and edge cases does JSON Minifier support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Whitespace Stripping | Rule | RFC 8259 | Removes spaces, tabs, CR, and LF outside of string literals. |
| JSONC Comments | Sanitizer | Stripped | Detects and strips // and /* */ comments without damaging string contents. |
| Gzip Size | Metric | Measured | Compressed with the browser's native gzip encoder. Falls back to an entropy estimate (shown as "~") where CompressionStream is unavailable. |
| Key Shortening | Analytics | Reported | Catalogs repeated keys longer than 3 characters and computes potential byte savings. |
Frequently asked questions
How does minification reduce API response latency?
Minification directly reduces the raw byte payload transferred over TCP/QUIC packets. For payloads spanning multiple MTU frames (1500 bytes), dropping dead whitespace reduces the number of round-trips and lowers browser parsing CPU cycles.
Does minifying JSON affect data types or float precision?
No. The minifier operates strictly on JSON syntax tokens. String literals, numbers, decimal precisions, and boolean values remain identical down to the bit.
Why does the tool show a Gzip size?
Almost all production web servers (Nginx, Cloudflare, Envoy) apply gzip or brotli compression to JSON responses, so an uncompressed byte count overstates what actually crosses the network. The figure shown is produced by your browser's own gzip encoder via the CompressionStream API, which means it is the real compressed size rather than a model of it. On a browser without that API the tool falls back to an entropy-based approximation and prefixes the number with a tilde.
Is my minified JSON processed on a server?
Never. All parsing, minification, and compression analytics execute 100% locally in your browser memory. No data is ever sent to any remote server.
How much smaller does minifying JSON actually make a payload?
Indented JSON is typically 10–30% whitespace, so that is roughly what minification takes off the raw byte count. After gzip the saving is far smaller, because compressors are very good at long runs of spaces — which is exactly why this tool shows both numbers side by side rather than only the flattering one.
Is minifying worth it when my server already compresses responses?
Often only marginally, and the point of showing both figures is to let you decide with a number instead of a habit. It still pays for JSON embedded in HTML or in a URL, for anything served without compression, and for payloads stored at rest by the byte. It rarely pays for an ordinary gzipped API response, where the difference can be under one percent.