Minify your JSON into a compact JSON file by removing extra whitespace, then download the optimized result in seconds.
.json file onto the Input (JSON) panel, paste directly, or load from a URL. The editor accepts pretty-printed, tab-indented, two-space, or already-minified JSON in any size your browser can hold in memory.JSON.parse() then JSON.stringify(obj) with no spacing argument. All insignificant whitespace, newlines, and indentation are stripped; strings, numbers, key names, and structure are preserved byte-for-byte. The Output panel shows the compact result with before/after byte counts..json. Nothing leaves your browser — the parse/stringify round-trip runs entirely on window.JSON.JSON minification removes every byte the JSON spec considers optional: space, horizontal tab, line feed, and carriage return outside of string literals. The resulting payload is semantically identical to the input — JSON.parse() returns the same object tree — but smaller on disk and over the wire. The savings depend entirely on how the source was formatted: a file pretty-printed with 4-space indents and trailing newlines can shrink 30-40%, while a file already serialized with JSON.stringify(obj) is a no-op.
JSON.stringify(obj, null, 2) calls in handler code leak indentation. Minifying before sending shaves bytes off every request before gzip even runs.<script type="application/json"> blocks for Next.js __NEXT_DATA__, Nuxt __NUXT__, or Redux preloaded state are unzipped on the wire if they're rendered by the framework on the server, but the raw HTML still gzip-compresses better when the JSON inside is already minified — and the parse step on the client is identical either way.QuotaExceededError on cache-heavy SPAs.package-lock.json, composer.lock, and Pipfile.lock are minified by their tools precisely because they're machine-read, frequently re-hashed, and committed thousands of times. Hand-written configs go the other way (formatted for diffs); shipped artifacts get minified.JsonLayout) emits one object per line. Most libraries already minify by default; if yours doesn't, indented log lines explode S3 / CloudWatch / Datadog ingest bills with nothing but whitespace.| Operation | What it does | When to use | XConvert tool |
|---|---|---|---|
| Minify | Strips whitespace; produces shortest valid JSON | Production APIs, storage, embedding, shipping | This page |
| Format (Beautify) | Adds indentation and newlines for readability | Debugging, code review, manual editing | JSON Formatter |
| Validate | Parses input and reports syntax errors with line/column | Diagnosing a parse failure before fixing | JSON Validator |
| Convert | Transforms JSON to/from CSV, YAML, XML | Pipeline interop with non-JSON systems | JSON to YAML, JSON to CSV, JSON to XML |
The percentage saved depends on how the original was indented. Numbers below are for typical API-shaped JSON (nested objects, short string values, mixed types):
| Source format | Sample input | Output | Reduction |
|---|---|---|---|
| 4-space indent + newlines | 1.00 KB | 0.55 - 0.70 KB | 30 - 45% |
| 2-space indent + newlines | 1.00 KB | 0.70 - 0.85 KB | 15 - 30% |
| Tab indent + newlines | 1.00 KB | 0.75 - 0.88 KB | 12 - 25% |
| Already compact | 1.00 KB | 1.00 KB | 0% |
| String-heavy (long values, few keys) | 1.00 KB | 0.92 - 0.98 KB | 2 - 8% |
| Deeply nested with short values | 1.00 KB | 0.40 - 0.60 KB | 40 - 60% |
For wire transfer, the more important number is what happens after gzip. Gzip is excellent at compressing repetitive whitespace, so the gap between gzipped-pretty and gzipped-minified is usually only a few percent — but minifying still wins because the uncompressed size that the browser parses is smaller, and not every consumer (especially intra-datacenter calls without HTTP compression) sees the gzip benefit.
For typical pretty-printed API JSON with 2-space indentation, expect 15-30%; with 4-space indentation, 30-45%. Heavily nested objects with short values save more (40-60% is realistic) because the indentation-to-content ratio is higher. JSON dominated by long string values (e.g., base64-encoded blobs, prose, URLs) barely changes — the strings themselves are untouched. Run your own file through and look at the byte-count display on the Output panel for the exact number.
Slightly. The download is smaller (proportional to the savings above), so over the wire it's measurably quicker on slow networks. Parse time is almost identical because JSON.parse() skips whitespace in O(n) regardless of how much there is — modern V8 / SpiderMonkey / JavaScriptCore parsers process hundreds of MB/s either way. The real win is bandwidth and storage, not CPU.
Not pointless, but the gain is smaller than you'd think. Gzip compresses repeated whitespace efficiently, so a pretty-printed JSON response often gzips to within a few percent of the minified-then-gzipped version. The cases where minification still matters: (1) clients without gzip (some embedded HTTP libraries, intra-VPC calls), (2) storage (gzip is for transfer, not for what you persist to S3 / DynamoDB / localStorage), (3) embedded inline JSON in HTML where the HTML is gzipped as one stream and any whitespace adds up across many script blocks.
Yes for production endpoints serving programmatic consumers — browsers, mobile apps, server-to-server. Default frameworks like Express's res.json() and FastAPI's JSONResponse already do this. No for debug or developer-facing endpoints where humans pipe responses to a terminal — pretty-printed is fine there, especially if you also support a ?pretty=1 query param like the GitHub API does. Internal admin tools usually don't need minification at all.
Standard JSON (per RFC 8259) has no comments, so there's nothing to remove — JSON.parse() will throw SyntaxError on any // or /* */ it encounters. If your input is JSON5 or JSONC (the comment-tolerant superset used by VS Code's tsconfig.json, settings.json, etc.), this minifier will reject it because it uses the browser's native JSON.parse(). Strip comments in your editor first (most editors highlight them), or use a JSON5 parser to round-trip through standard JSON.
No. Whitespace outside of string literals is purely cosmetic in the JSON grammar — section 2 of RFC 8259 declares space, tab, LF, and CR as insignificant between tokens. Any conforming parser handles minified and pretty-printed input identically. The only thing that "breaks" is human readability; run the output back through the JSON Formatter any time you want to re-inspect it.
No, the minifier preserves whatever order the parser hands back. In ECMAScript 2015+ (V8, SpiderMonkey, JavaScriptCore, modern Edge), JSON.parse() returns objects with keys in insertion order, with one wrinkle: integer-string keys ("0", "1", "42") come first in ascending numeric order, then all other string keys in insertion order. ES2020 codified this in the spec, so behavior is consistent across modern browsers. The JSON spec itself doesn't require ordered objects, so don't rely on key order for canonicalization (signing, hashing) — sort explicitly if you need a stable representation.
Possibly, depending on your machine. The bottleneck is that JSON.parse() builds the entire object tree in memory before JSON.stringify() re-serializes it, so peak memory is roughly 2-3x the file size. A 100 MB JSON file may need 300-500 MB of JS heap, which exceeds Chrome's default tab limit on 32-bit systems and stresses 64-bit ones. For multi-gigabyte logs or NDJSON, use a streaming tool like jq -c on the command line, or process line-by-line with JSONStream in Node.
Either your input was already minified (no whitespace to remove), or your file is dominated by string content rather than structural whitespace. JSON with "description": "a very long string value..." only minifies whatever sits between the structural tokens — the string body itself is preserved verbatim, escapes and all. Check the byte count to confirm: if you see "0% reduction", the file is already as small as JSON minification alone can make it.