Formatter Validator Minifier Escape / Unescape JSON ↔ String JSON ↔ YAML JSON → CSV NDJSON / JSON Lines JSON → Types JSON ↔ XML JSON Diff JSON Patch Canonicalize (RFC 8785) Schema Validator Schema Generator JSONPath Tester JWT Decoder JSON Errors Schemas More Tools
Compact JSON · Reduce payload size · Save bandwidth

JSON Minifier Online

Compress JSON to a single line by removing all unnecessary whitespace, preserving the data exactly. Across 799 real-world documents the median saving is 36.1% of raw bytes — and 11.6% once your server is already gzipping. Both numbers are measured; see below.

Input JSON 0 bytes
1
Minified output 
Minified JSON will appear here
What is JSON minification?

What is JSON minification?

JSON minification is the process of removing all unnecessary whitespace from a JSON document to produce the smallest valid representation of the same data. Where pretty-printed JSON uses indentation, line breaks, and spaces for readability, minified JSON squeezes everything onto a single line with no whitespace at all.

The data itself is unchanged — every key, value, type, and structural element is preserved exactly. Minification is purely cosmetic: it strips characters that don't affect parsing. A JSON parser produces the same in-memory result whether it reads minified or pretty-printed input.

So why bother? Because whitespace adds up. A typical pretty-printed JSON with 2-space indentation is 40-60% larger than its minified equivalent. With 4-space or tab indentation, the difference is even bigger. For API responses sent thousands or millions of times per day, that translates to real bandwidth, real latency, and real money.

How to minify JSON online

How to minify JSON online

Three steps:

  1. Paste your JSON into the input panel — formatted or already minified, either works. You can also upload a .json file or drag and drop one.
  2. Click Minify. The output appears immediately in the right panel as a single compact line.
  3. Copy or download the minified result. The status message shows exactly how many bytes you saved.

The tool also works in reverse — click Expand to convert minified JSON back to pretty-printed form. Use this when you receive a minified API response and want to read it.

When should you minify JSON?

When should you minify JSON?

Minification helps in any context where JSON is transmitted, stored, or transferred in volume:

API API responses

Production APIs almost always return minified JSON. With responses going out thousands of times per second, removing 50% of the bytes meaningfully reduces server bandwidth costs and improves response time.

DB Database storage

If you store JSON in a database column (PostgreSQL jsonb, MySQL JSON, MongoDB), minification reduces storage size, speeds up reads, and reduces network transfer between database and application.

URL Query parameters

JSON embedded in URLs needs to fit in the URL length limit (typically 2048 chars). Minify first, then URL-encode, to stay under the limit and keep URLs reasonably short.

MQ Message queues

Kafka, RabbitMQ, AWS SQS, and similar systems often charge by message size. Minified JSON reduces per-message cost and lets you fit more data inside fixed message limits.

JS Frontend bundles

JSON configs embedded in webpack/Vite bundles add directly to your JS bundle size, which slows page load. Minified configs shrink the bundle.

↻ Webhook payloads

Stripe, GitHub, Slack, and other webhook providers often have payload size limits (256 KB typical). Minification fits more data into a single hook.

How much does minification actually save?

How much does minification actually save?

The savings depend on your indentation style and how deeply nested your data is:

  • 2-space indent → minified: roughly 30-40% size reduction. This is the most common starting point.
  • 4-space indent → minified: roughly 50-60% reduction. Tab indentation falls in this range too.
  • Deeply nested structures save more. Each level of nesting adds more whitespace per byte of actual data, so trees with depth 10+ can save 70%+.
  • Compression on top of minification helps further. If you serve JSON with gzip or brotli enabled (which you should), minified JSON compresses to roughly the same size as pretty-printed JSON — both are dominated by the repeated key strings. But minification is still a win because (1) it's smaller pre-compression, reducing memory use on the server, and (2) clients without compression support get the smaller payload directly.
When NOT to minify JSON

When NOT to minify JSON

Some scenarios where pretty-printed JSON is the better choice:

  • Configuration files in source control. package.json, tsconfig.json, .eslintrc.json — keep these pretty-printed so git diffs show meaningful changes rather than "the whole file changed".
  • Documentation and examples. JSON shown in API docs or tutorials should be pretty-printed for readability.
  • Logs and audit trails. Human-readable formatting helps when you're scanning logs by eye, though tooling like jq can reformat on demand.
  • Small files where the savings are negligible. A 200-byte config file doesn't benefit meaningfully from minification.
  • Debug environments. During development, pretty-printed responses from your own API are easier to inspect in browser DevTools.

The rule of thumb: minify for production transmission and storage; keep it pretty for development, source control, and documentation.

Common questions

FAQ — Json Minifier

What does it mean to minify JSON?
Minifying JSON means removing all unnecessary whitespace — spaces, tabs, newlines — to produce the smallest valid representation of the same data. The data itself doesn't change; only the formatting does. A minified JSON file parses to exactly the same in-memory object as its pretty-printed equivalent.
How much smaller will my JSON be after minification?
Typically 30-60% smaller. The exact amount depends on indentation style (4-space indent saves more than 2-space) and nesting depth (deeper nesting saves more). Run your file through the tool to see the precise saving for your specific data.
Will minification break my JSON?
Only if your JSON was invalid to begin with. The minifier first parses the JSON (which rejects invalid input) and then re-serializes it without whitespace. If your original is valid, the minified version is guaranteed to be valid too — and to parse to identical data.
Is minified JSON valid JSON?
Yes. The JSON specification doesn't require whitespace anywhere — it's purely optional, added for human readability. Every JSON parser handles minified JSON identically to formatted JSON.
Can I un-minify (expand) minified JSON?
Yes — this tool's Expand button does exactly that. It re-formats minified JSON with proper indentation. Since the data is identical, expanding is just the reverse operation.
Should I always minify production JSON?
Generally yes for API responses, storage in databases, and over-the-wire transmission. But not for files checked into source control (configs, schemas, fixtures) — those should stay pretty-printed for diff readability.
Does gzip make minification unnecessary?
Mostly, but not entirely. Gzip/brotli compress both pretty and minified JSON to similar final sizes — repeated key strings dominate the compressed size. But minified JSON has these advantages: (1) less memory used on the server before compression; (2) clients without compression support get the smaller payload directly; (3) JSON stored in databases is rarely compressed, so storage savings are real.
Does minification affect numeric precision or Unicode?
No. Strings are preserved byte-for-byte — including Unicode escapes, control characters, and any special encoding. Numbers are re-serialized in their canonical form, but the precision is the same as parsing them produced. The only thing that changes is whitespace between tokens.
Can I minify huge JSON files?
The browser handles documents up to about 50 MB comfortably. For larger files, use a streaming command-line tool like jq -c . file.json > file.min.json — that's the canonical way to minify large JSON outside a browser.
How does this compare to other JSON minifiers?
Functionally identical to most online minifiers — JSON minification is a well-defined operation with no creativity involved. The differentiators here are (1) browser-side processing (your JSON never touches a server), (2) bidirectional (minify and expand in the same tool), (3) instant feedback showing exact bytes saved.
Why is my minified JSON still big?
If your JSON is large after minification, the data itself is large — there's no further size reduction available through formatting. Consider: (1) is there data you don't actually need? (2) are key names unnecessarily verbose (could you shorten customer_billing_address_line_1 to addr1)? (3) should you compress with gzip/brotli on top?
Measured

How much does minifying actually save?

Most minifier pages quote a raw-byte figure and stop there. That number is real, but almost every JSON response is served over a compressed connection, and compression already removes most of what minifying removes. Both numbers below come from running the same 799 real-world JSON documents through every combination.

Comparison Median saving Range
Minifying, uncompressed bytes 36.1% 2.3% – 70.6%
Minifying, when gzip is already on 11.6% 0.7% – 58.2%
gzip alone, on the formatted file 82.8% —
Switching gzip → brotli, already minified 17.8% —

Read that as: minifying is worth doing, and it is not the big lever. Compression is. If you are shipping JSON uncompressed, turning compression on is worth roughly seven times more than minifying, and switching from gzip to brotli is worth more than minifying on top of gzip.

Where minifying still matters plainly: storage and log volume, embedding JSON in a URL or a database column, anything not served over HTTP, and the 58.2%-saving tail — deeply indented documents with short values, where whitespace is a large share of the content even after compression.

799 documents from the SchemaStore catalogue, 2 KB to 2 MB. gzip level 6, brotli at default quality. Full write-up →

Behind the scenes

Everything on this page runs in your browser — no upload, no server-side processing. How it works →