JSON is the simplest format in this whole minifier series. The grammar is one page long. There are no comments. There are no optional semicolons. There are no whitespace-sensitive constructs. Minifying JSON is almost trivial — you remove every character that isn't inside a string or part of a token. That's it.

And yet JSON shows up in more places than any other format on the web, and minifying it correctly still trips people up. Let's walk through what minification actually does to a JSON document, why the math is different from HTML or CSS, and when you should reach for this tool versus leaving the whitespace in.

The One-Line Recipe

In JavaScript, JSON minification is literally:

JSON.stringify(JSON.parse(input))

Parse the input to a value, stringify the value without any indent argument. That's the minified form. The parse step validates; the stringify step produces the canonical compact serialization. Every mainstream language has the equivalent two-line operation.

This is why our JSON Minifier is almost embarrassingly short — most of the file is UI and copy-paste convenience. The actual minify is a single function call. The trick isn't the minification; it's the error handling around bad JSON input.

What Actually Gets Removed

Only whitespace between tokens, never whitespace inside strings. These are both valid JSON:

{ "name": "Ur Next Door", "description": "Hello World" }
{"name":"Ur Next Door","description":"Hello World"}

Notice how the two-space sequence inside "Hello World" is preserved. String contents are data — touching them changes the value. That's also why naïve regex approaches ("replace all whitespace with nothing") are wrong; they destroy data. A real JSON minifier parses to a value first so strings are distinguishable from structural whitespace.

How Much You Save

Pretty-printed JSON is typically 30–60% larger than minified. The exact ratio depends on nesting depth. A flat object with five keys saves 10–15%. A deeply nested tree of arrays of objects can save 60%+ because every indentation level adds spaces that multiply across thousands of lines.

After gzip, the saving shrinks significantly — JSON is highly repetitive and gzip absorbs a lot of the whitespace redundancy. Minified-gzipped vs. pretty-gzipped is often within 5–10% of each other. But the uncompressed size still matters for parse time and memory on the client. If your client is a mobile browser parsing a 2MB response, saving 600KB of uncompressed bytes means 600KB less work for the JSON parser, regardless of how well gzip handled it in transit.

JSON Minification vs. Other Formats

JSON has three unusual properties that make minification safer than for HTML, CSS, or JS:

  • No comments. JSON literally does not support // or /* */. If you see them, someone fed you JSON5 or JavaScript object literal syntax, not JSON. Nothing to strip.
  • No optional tokens. Unlike JS's ASI or CSS's optional trailing semicolon, JSON has no "you can leave this out if you feel like it" tokens. The grammar is completely unambiguous.
  • No execution. JSON is pure data. There's no equivalent of CSS's calc() or JS's dynamic property lookups. Every byte is either structure, a string literal value, a number, a boolean, or null.

Put together, this means you can minify JSON without worrying about any of the edge cases that plague the other formats. If the parse succeeds, the minify is guaranteed safe.

When to Minify JSON

API payloads

Most production APIs already ship minified JSON. The common exception is internal or debug endpoints where a human reads the response. If you're building a public API, ship minified — your clients' bandwidth bills will thank you.

URL parameters

Occasionally you need to pass a JSON blob through a query string or fragment. URL-encoding the minified form is much shorter than encoding the pretty form. Bear in mind browsers cap URL length around 2KB in practice — for anything bigger, use POST with a request body.

Database columns

Postgres, MySQL, and SQLite all have JSON/JSONB column types. Most of them store a normalized internal representation, so minification on input is irrelevant — the database is storing structure, not your text. But if you're storing JSON as a plain text column (common in legacy schemas), minify first.

Embedded in HTML

Server-side frameworks often inline bootstrap data as <script id="state" type="application/json">{...}</script>. The whole blob becomes part of your HTML response, so minifying the JSON portion shrinks the page. (Remember to HTML-escape the < and > that might appear in string values.)

Log lines

Structured logging frameworks (Winston, Bunyan, Zap) emit one JSON object per line. They always minify — a log record with multiline JSON would break line-oriented parsing tools like grep, awk, and Splunk ingest. You rarely do this manually; the logger handles it.

When to Keep It Pretty

  • Config files committed to git. Pretty JSON makes diffs readable and merge conflicts tractable. Don't minify your package.json.
  • Documentation and tutorials. A minified response is unreadable; a pretty-printed one teaches.
  • Development. Any intermediate data you're going to re-read should stay pretty.

A common pattern: minify on the wire, keep pretty on disk. Your static site generator takes a pretty data.json at build time, generates pages, and serves minified JSON in the rendered HTML. You never write minified JSON by hand.

Error Recovery

If minify fails, the input is invalid JSON. The parser will tell you where. Common culprits:

  • Single quotes instead of double. JSON only accepts "double quotes" around strings and keys.
  • Unquoted keys. {name: "foo"} is a JavaScript object literal, not JSON.
  • Trailing commas. {"a": 1,} is invalid — the last element has no comma.
  • Comments. The usual temptation in config files. Use JSON5, JSONC, or YAML if you need those, not JSON.
  • undefined, NaN, or Infinity — not valid JSON values. You have null, numbers (not including NaN/Inf), strings, arrays, objects, and booleans. That's the full list.

If you're getting Unexpected token errors at minify time, copy your input into a validator first. Our JSON Formatter has a validate button that highlights the exact column of the first syntax error.

Bottom Line

JSON minification is the safest minification in this series. Parse, stringify, done. You can do it in two lines of code in any language. If you have a one-off JSON blob you need compacted — an API response for a bug report, a payload for a URL, a snippet for a log line — paste it into our JSON Minifier, hit the button, copy the result. No installs, no uploads, no gotchas.

Read next

Related Guides