Skip to content
LocalOnly

JSON Minifier

Stable

Strip whitespace to shrink JSON to the smallest valid payload.

Everything is processed locally in your browser

About JSON Minifier

The JSON Minifier removes every unnecessary space, tab, and newline to produce the most compact valid JSON possible. Smaller payloads mean faster API responses, cheaper storage, and less bandwidth on the wire. The tool validates while it compresses, so you never ship malformed output.

Features

  • Removes all insignificant whitespace, tabs, and line breaks
  • Validates input before minifying to guarantee valid output
  • Reports the byte size before and after so you can see the savings
  • Preserves strings and escape sequences exactly, including spaces inside values
  • Handles deeply nested structures and large arrays
  • One-click copy of the minified string

How to use JSON Minifier

  1. 1

    Paste formatted JSON

    Add the pretty-printed or spaced-out JSON you want to compress.

  2. 2

    Minify

    The tool strips all non-essential whitespace and outputs a single-line document.

  3. 3

    Review the savings

    Check the before-and-after byte count to confirm the size reduction.

  4. 4

    Copy or download

    Use the compact result directly in requests, config, or storage.

Examples

Formatted input to minified output

Input

{
  "product": "Widget",
  "price": 19.99,
  "tags": ["new", "sale"]
}

Output

{"product":"Widget","price":19.99,"tags":["new","sale"]}

How JSON minification works

What minifying actually saves

Minifying JSON removes every byte that the parser does not need: the line breaks between entries, the indentation at the start of each line, and the spaces after colons and commas. Nothing inside a string literal is touched, and no key or value is altered. The result parses to exactly the same value as the input.

The saving depends entirely on how deeply nested the document is. A flat object with long string values might shrink by 5%, because most of the bytes are content rather than structure. A deeply nested configuration file with short keys and four-space indentation can lose 40% or more, because indentation dominates. Somewhere around 10-25% is typical for real API payloads.

Minifying is not the same as compressing - and gzip changes the maths

This is the part that gets skipped in most explanations, and it changes when minifying is worth doing. Indentation is the single most compressible thing in a text file: it is long runs of identical bytes, which is exactly what gzip and Brotli are built to collapse. If your server already compresses responses - and it almost certainly does - most of the benefit of minifying has already been captured before the bytes hit the wire.

A concrete way to think about it: a formatted document that is 30% larger than its minified form is often only 2-5% larger once both are gzipped. So minifying for network transfer is real but modest when compression is on, and dramatic when it is off.

Where minifying still clearly wins is anywhere compression does not reach. Values stored in a database column, payloads embedded in a URL or a QR code, records written to a size-capped log field, data held in `localStorage` against a hard quota, and message bodies on queues that bill per byte. In those places the raw byte count is the byte count, and whitespace is pure cost.

What minifying deliberately leaves alone

Key names are untouched. Minifiers for JavaScript rename variables because the new names are internal, but a JSON key is part of a contract with whatever reads the document. Shortening `"description"` to `"d"` would save bytes and break every consumer, so no JSON minifier does it.

Structure is untouched too. Redundant nesting is not flattened, repeated sub-objects are not deduplicated into references, and empty objects and arrays are kept. Those would all be changes to the data model rather than to its presentation. If a document is bloated because of its shape rather than its whitespace, minifying will not help much - restructuring it will.

Reference

Where the bytes actually go

Approximate figures for a typical nested API response, showing why compression settings matter more than whitespace.

FormRelative sizeBest used for
Formatted, 4-space~135%Reading, reviewing, committing to a repo
Formatted, 2-space~120%The common default for source control
Minified100%Storage columns, URLs, size-capped fields
Formatted + gzip~26%HTTP responses with compression enabled
Minified + gzip~24%The same, with a marginal further saving

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You are storing JSON in a database column or a cache entry
Minify. Compression usually does not apply at this layer, so every whitespace byte is paid for on every row.
You are shrinking an HTTP response
Check that gzip or Brotli is enabled first. That single setting is worth far more than minifying, and once it is on the extra gain from minifying is small.
You need to read the document afterwards
Do not minify - use the JSON Formatter. Minified JSON on one line is exactly as hard to debug as it looks.
You need to embed JSON inside another JSON string or a code literal
The JSON Stringify tool is the right one. It escapes the document for nesting, which minifying alone does not do.
The document is large because of its shape, not its spacing
Minifying will disappoint. Look at the JSON Statistics tool first to find the repeated structures or oversized arrays that are actually driving the size.

Use cases

  • Reducing the size of API request and response bodies
  • Embedding JSON into environment variables or query strings
  • Trimming configuration files before committing them
  • Cutting bandwidth for high-traffic endpoints
  • Storing JSON in size-limited fields or caches

Troubleshooting common errors

The minified output is barely smaller than the input

Why: The document was already compact, or its bytes are dominated by long string values rather than structural whitespace.

Fix: Nothing to fix - this is the honest result. If size is still a problem, the issue is the data itself rather than its formatting.

Minifying fails with a syntax error

Why: Minifying requires a successful parse, so any malformed JSON stops it. Trailing commas and single quotes are the usual culprits.

Fix: Run the document through the JSON Formatter first to get the exact line and column of the problem, correct it, then minify.

The minified JSON breaks when pasted into a shell command

Why: Double quotes in the JSON are being interpreted by the shell before your program sees them.

Fix: Wrap the whole payload in single quotes, or write it to a file and pass `@file.json` to your client. Minifying makes this more visible because everything is now on one line.

A very large number changed value after minifying

Why: Not a minifier bug. Parsing converted the integer to a double and lost precision above 2^53, and the minified output reflects the parsed value.

Fix: Emit large identifiers as strings from the source system. This affects formatting and minifying equally.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

  • Key names are never shortened - they are part of your data contract, not an internal detail.
  • Repeated sub-objects are not deduplicated and redundant nesting is not flattened. Minifying changes presentation only.
  • Comments are removed, since JSON has no comment syntax and the document is rebuilt from parsed values.
  • Where HTTP compression is already enabled, the additional saving over a formatted document is usually only a few percent.
  • Numbers are normalised to their shortest round-trip form, so `1.0` becomes `1`.

Frequently asked questions

Learn more

Command Palette

Search for a tool or command