A JSON minifier parses JSON and re-emits it with all insignificant whitespace removed. The tool above runs the minifier in your browser; nothing leaves your machine. For the inverse direction, see JSON formatter.

What gets stripped

JSON has a strict grammar — much simpler than HTML or CSS — and the minification rules are correspondingly clean.

Whitespace	Strippable?
Space/tab/newline between tokens	Yes
Space inside a string literal	No — significant
Newline inside a string literal	No — and JSON forbids literal newlines inside strings
Indentation	Yes
Trailing newline at end of file	Yes

The rule: any whitespace that’s not inside a "..." string is insignificant and gets stripped.

Input (formatted):
{
  "name": "Alice",
  "age":  30
}

Output (minified):
{"name":"Alice","age":30}

Size reduction depends on the input’s formatting style:

4-space-indented JSON: ~30–50% size reduction.
2-space-indented JSON: ~15–25% reduction.
Already-compact JSON with single-space separators: ~5–10% reduction.

What’s safe vs unsafe

JSON minification is one of the safer minifications. Unlike CSS, HTML, or JavaScript, JSON has no optional syntax to deal with. There’s no equivalent of “missing semicolon,” “implicit closing tag,” or “operator precedence ambiguity.” If the input parses, the output is the same data structure.

The only risks:

Whitespace inside string literals. The minifier must preserve "hello world" as-is, not collapse it to "helloworld". A correct minifier parses tokens; a regex-based minifier risks getting this wrong.
Comments. JSON has no comments. A “JSON” file with // or /* */ is JSONC or JSON5, not strict JSON. A strict JSON minifier rejects these as parse errors. A permissive parser (like Node’s experimental JSONC support, or a JSON5 parser) accepts them; some minifiers strip them, others preserve them.
Trailing commas. Strict JSON forbids them. JSON5 allows them. A strict minifier rejects them; a JSON5-aware one accepts them and may emit them or strip them.

The tool above accepts strict JSON only. For JSONC/JSON5 input, run it through the JSON formatter’s Lenient mode first, then minify the result.

Minified vs gzipped

JSON minification on the wire is largely redundant if the response is gzipped. Gzip and brotli compress repeated whitespace efficiently — a 4-space-indented JSON file gzipped is only marginally larger than a minified-then-gzipped one (usually within 5%).

When minification still matters:

Inline JSON in HTML. No file-level compression on the inline portion.
JSON stored at rest without compression (database BLOBs, S3 objects without gzip).
Embedded JSON in environment variables or shell scripts. Compactness is the only saving lever.
Mobile/IoT clients without compression support. Bytes count more.

When it doesn’t matter:

Standard HTTP API responses. Gzip the output; minify or don’t, the size on the wire is similar.
Development debugging. Always use formatted JSON locally.

When not to minify

Source-controlled JSON. Configuration files, schemas, package.json. Diffs are unreadable when the file is one giant line.
JSON in documentation. Examples in tutorials and READMEs.
JSON the user will read. API responses you expect humans to inspect during debugging.

The right pattern for production: keep formatted JSON in the source repo, minify in the build step that ships to clients.

What about JSONC and JSON5?

These are JSON-with-extensions:

JSONC (JSON with comments) — JSON plus // and /* */ comments. Used by VS Code config, tsconfig.json, some other tooling.
JSON5 — JSONC plus trailing commas, single quotes, unquoted keys, multi-line strings.

A strict JSON minifier rejects both. A JSONC-aware minifier strips comments. A JSON5-aware minifier converts to strict JSON (single quotes → double, unquoted keys → quoted, trailing commas removed) and then minifies.

If your “JSON” doesn’t parse with a strict parser, identify which dialect it actually is and use the right tool.

Common pitfalls

Re-minifying minified JSON. Idempotent for proper minifiers; wastes a parse pass if the input is already minified. Most tools detect and short-circuit.
Minifying invalid JSON. Strict parsers fail loudly with a position. The tool above reports the first invalid character and where it is.
Trailing newlines. A JSON file ending with \n is technically valid; minified output has no trailing newline. If your downstream consumer is picky about a trailing newline, add it back.
BOM (byte-order mark). A file starting with EF BB BF is technically valid UTF-8 but can confuse strict JSON parsers. Strip BOMs before minifying.
Confusing minification with transformation. Minification changes formatting only. To shrink the JSON further (drop fields, restructure), you need a transformation step on top.

For the inverse direction, see JSON formatter. For other minification needs, see HTML minifier, CSS minifier.

JSON Minifier