JSON Compression Minifier

1. 1

   Paste or upload JSON

   Paste your JSON into the text box, or drag a file onto the drop area. Formatted and already-minified JSON both work, and so do .jsonc, .ndjson, .geojson, .har, .map and .webmanifest files.

2. 2

   Pick a dialect if you need one

   Strict JSON is the default. Switch to Relaxed for files with comments or trailing commas, and tick JSON Lines for files holding one document per line. If the strict pass fails, the tool tests the other modes and offers the one that actually works.

3. 3

   Minify

   Press Minify. The file is scanned off the main thread, so the page stays responsive and you can cancel. You see the size before, the size after, the percent saved, and — because that is the number that reaches the wire — the gzipped size before and after.

4. 4

   Download or copy

   Download the result as filename.min.json, or copy it to the clipboard. With several files minified, one button collects all of them into a single ZIP.

This free JSON minifier removes the whitespace between tokens so your JSON becomes a single compact line, and it does it without touching your data. Paste or drop a file, press Minify, and you get the size before, the size after, the percent saved and the gzipped size on both sides — the last of which is the number that actually reaches the network. Invalid input gets a line, a column and a caret under the character that broke, plus the mode that would have worked if the file is really JSONC or JSON Lines. Everything runs on your device; nothing is uploaded.

• Lossless output — Long numbers, trailing zeros, key order and repeated keys all survive, because no value is ever built. Only whitespace between tokens is removed.
• Two size stories — Raw bytes saved and gzipped bytes saved, side by side. Minifying often saves 45% raw and 4% compressed, and you should know which one you are buying.
• Errors you can act on — Line, column, the offending line with a caret, and a description of what was expected — not a parser message with a character offset in it.
• The dialects people actually have — Strict JSON, JSONC with comments and trailing commas, and JSON Lines with one document per line. The tool tests them for you when the strict pass fails.
• Paste or files — Type or paste into the box, or drop .json, .jsonc, .ndjson, .jsonl, .geojson, .har, .map, .webmanifest and .txt files. UTF-8 and UTF-16 are both read, with or without a byte-order mark.
• Batch on Pro — Up to 20 files in one pass, each named filename.min.json, collected into a single ZIP.

Almost every JSON minifier — including the one that used to be on this page — works by parsing your document into values and printing them again. That is a re-serializer, not a minifier, and it changes your data in seven ways that all look completely fine in the output. The table below is measured, not hypothetical: it is what the old implementation on this page produced.

This tool takes the other approach. It scans the bytes of your file and copies each token — every string, every number literal, every true, false and null — through to the output untouched, emitting only the structural punctuation between them. A number is never interpreted, so it cannot be re-rendered. A member is never stored in an object, so it cannot be reordered or deduplicated. An escape is never decoded, so it cannot change form. The only bytes that disappear are the whitespace characters between tokens, which is the definition of the word minify.

JSON has exactly four whitespace characters — space, tab, carriage return and line feed — and they are insignificant only when they sit between tokens. Inside a string they are data.

• Removed — Indentation, the newline after every comma, the space after a colon, and any blank lines around the document. In relaxed mode, comments and a trailing comma go too.
• Kept exactly — Every character inside a string, including the spaces in "John Smith" and any escape sequence written there. Every digit of every number. The order of every member. Every repeated key.
• Never added — No key is quoted differently, no number is reformatted, no escape is introduced. If your file was already minified, the output is byte-identical to the input and the tool reports a 0% reduction rather than pretending otherwise.

A minifier that shows you only the raw saving is showing you the flattering number. Indentation is the most compressible content that exists — long runs of identical spaces — so gzip and brotli have usually already removed almost all of it before your bytes reach the network. That does not make minifying pointless; it makes the honest measure the compressed one.

• Where minifying pays a lot — Anything not served over a compressing transport: a config file read from disk, a payload embedded in a bundle, a document stored in a database column, a body posted from a device that does not compress its requests.
• Where it pays a little — A gzip- or brotli-compressed HTTP response. Expect single-digit percentages on top of what compression already did, which is often still worth having but is not the 45% the raw number promised.
• Where it pays in parse time — Smaller uncompressed text is less for the parser to walk, on every client, on every request — a cost that does not disappear just because the bytes compressed well.
• How to read the two lines — The card under each file shows raw before, raw after and percent, then the same three for the gzipped sizes. If the second line barely moves, minification is not the lever you want for that file.

The JSON specification has no comments and no trailing commas. The files on your disk very often do, because the format outgrew its spec the moment tools started using it for configuration. Strict mode is the default here because a strict answer is the useful one when you are checking whether a payload is valid; relaxed mode exists because refusing tsconfig.json is not a principled stand, it is just unhelpful.

• Strict — RFC 8259 exactly. No comments, no trailing commas, no unquoted keys, no single quotes, no leading plus, no .5 or 5., no leading zeros, no raw control characters inside a string, no Infinity or NaN.
• Relaxed — Adds // line comments, /* block */ comments, and one trailing comma before a closing brace or bracket. Both are removed from the output, so relaxed mode turns a JSONC file into strict JSON as a side effect.
• Not JSON5 — Relaxed mode is JSONC, not JSON5. Unquoted keys, single-quoted strings, hex literals, Infinity and NaN are still refused, and .json5 is deliberately not in the accepted file list rather than half-supported.
• Told, not guessed — The tool never silently switches dialect. If the strict pass fails, it tries the others behind the scenes and offers you the one that succeeded as a button — so a suggestion is always something that has actually been proven to work on your file, not a guess from the error code.

A JSON Lines file is not one JSON document; it is many, one per line, which is why a normal parser stops at the end of the first one and complains about trailing content. Turn on JSON Lines and each line is minified as its own document and the line structure is kept, so the result is still a JSON Lines file.

• Why splitting on newlines is exact here — A raw newline inside a JSON string is a control character, which the specification forbids. No record can contain one, so a line break is always a record break — this is a guarantee, not a heuristic.
• Blank lines — Dropped. They carry no record, and keeping them in a minifier would mean preserving exactly the bytes the tool exists to remove.
• Errors point at the file — A failure in the four-thousandth record is reported with the line number in the whole file, not an offset inside that record, plus which record it was.
• The extension follows — A JSON Lines run downloads as .min.ndjson, never .min.json, because one document per line is not a single JSON value and naming it .json would hand you a file no parser accepts.

Many JSON writers escape every non-ASCII character defensively, so "你好" arrives as "\u4f60\u597d" — twelve bytes where six would do. Because both forms mean exactly the same string to every parser, converting them is a safe saving, but it does change the bytes, so it is off by default and clearly labelled.

• What it converts — Any \uXXXX escape whose character can be written directly: six bytes become one, two or three, and a twelve-byte surrogate pair for an emoji becomes four.
• What it refuses — \u0022 and \u005c, because a raw quote or backslash would end or restart the token. Anything below \u0020, because a raw control character inside a string is invalid JSON. And a lone surrogate, which has no UTF-8 form at all.
• Lone surrogates pass through — A lone surrogate escape — \u followed by a code from D800 to DFFF, with no partner — is accepted and copied out unchanged, exactly as the browser's own parser accepts it. It is six plain ASCII characters in the source and the same six in the output, so nothing is lost by leaving it alone.
• Off by default — Because with it off the output is byte-identical to the input token for token, and that guarantee is worth more than the bytes for most people.

A parser error is only useful if it tells you where to put the cursor. "Unexpected token } in JSON at position 4172" tells you neither the line nor the column, and no editor shows you position 4172. Every failure here is reported with the three things that let you fix it.

• Line and column — The column counts characters, not bytes, so the number matches what your editor shows even on a line containing emoji or CJK text.
• The line, with a caret — The offending line is shown, windowed if it is very long, with a caret under the exact character. Long lines scroll inside the card rather than stretching the page.
• What was expected — Distinct messages for a trailing comma, a comment in strict mode, a leading zero, a lone quote, an unterminated string, a raw control character, a bad escape, a bad hex digit, invalid UTF-8, and a document that ends early.
• A trailing comma is named as one — It is by far the most common mistake in hand-edited JSON, and the difference between "unexpected }" and "remove the comma before }" is most of the value of an error message.

The accepted list is closed and it is enforced at the file dialog, so you never pick a file and watch nothing happen. Everything on it is JSON; everything off it that we can help with is a link to the tool that handles it.

• Accepted — .json, .jsonc, .ndjson, .jsonl, .geojson, .har, .map, .webmanifest and .txt. A source map, a browser network export, a GeoJSON feature collection and a web app manifest are all JSON documents, and none of them could be selected before.
• Encodings — UTF-8 is expected. A UTF-8 byte-order mark is stripped rather than reported as a syntax error at character 0, and UTF-16 files are converted, with or without a mark. Invalid UTF-8 is reported with a position instead of being copied into the output.
• Redirected, not refused — A CSV goes to CSV to JSON, an XML to XML to JSON, a YAML to YAML to JSON, a spreadsheet to Excel to JSON. Each of those is a free tool on this site and the link goes straight to it.
• Not accepted — .js and .json5. A JavaScript file is a program, not a document, and JSON5 needs syntax this engine does not implement — listing either would promise something the tool cannot do.

Free minifies one file at a time, up to 25 MB, with every mode and every option available. Pro adds batch: up to 20 files queued together, each with its own before-and-after numbers, and one button that collects the results into a single ZIP.

• One archive, not twenty downloads — A twenty-file batch without a single archive means twenty browser save prompts, which is not a feature anyone would pay for.
• Names survive — Each result is named after its source — api-response.json becomes api-response.min.json — instead of twenty files all called minified.json. Two inputs sharing a name are suffixed so neither is lost inside the archive.
• Compressed, because it is text — The archive deflates its entries. Minified JSON is text and compresses to roughly a fifth, which matters to someone who came here specifically to make things smaller.
• The size cap — 25 MB per file on Free. On Pro the ceiling is what your device can actually handle, measured from the device rather than raised to another fixed number.

Minified JSON uses less bandwidth and less parse time in APIs, configs and front-end bundles. Removing whitespace does not change the data—only the representation—so it is safe for production, provided the tool doing it really only removes whitespace. This tool gives you both the raw and the compressed comparison so you can see what you actually save. If your JSON is already minified you will see no reduction; the output is still valid and ready to copy or download.

• Smaller payloads — Less data over the wire for APIs and mobile clients, and less text for every client's parser to walk.
• Same semantics, and here the same bytes — Parsed values are identical, and because no value is rebuilt, the tokens themselves are identical too.
• Configs and bundles — Files read from disk or embedded in a bundle are usually not served over a compressing transport, which is where minifying pays most.
• Nothing is uploaded — The whole scan runs on your device, not our servers, so a private API payload or a credentials-bearing HAR file is never uploaded.

The engine is a validating tokenizer that emits spans. It walks the file's bytes once, and every time it recognises a complete token it copies that token's bytes into an output buffer allocated at the input's size — the output of a minifier can never be longer than its input, so the buffer is never grown.

• Off the main thread — The scan runs in a worker, so a 25 MB file does not freeze the page, progress is a real byte count rather than an animation, and Cancel stops the work immediately.
• One pass, no value tree — Because no objects or arrays are built, memory stays at roughly a fifth of the file size instead of twice it, and long numbers keep every digit.
• Spans, not characters — Runs of ordinary text are copied in one operation rather than a character at a time, which is the difference between about 200 MB per second and about 77.
• The same code either way — If a worker cannot start, the identical functions run on the main thread. It is one implementation with two places to run it, so the fallback cannot produce different bytes.

The scanner reads about 200 MB of JSON per second and holds roughly a fifth of the file in memory while it works, because it copies token spans instead of building a value tree.

• JSON Formatter
• JSON Validator
• JSON Viewer
• JSON Escape
• JSON Merge
• Sort JSON Keys