JSON Minifier

Remove insignificant JSON whitespace without changing strings, number spellings, duplicate members, or key order.

JSON input

The input must be valid JSON. Spaces and line breaks inside string values are data and will not be removed.

The minification pass stays in this browser page; no request is made with the JSON you paste. Copying moves the result to your system clipboard, while browser extensions and site-wide analytics or advertising scripts are outside that processing boundary. Validation and scanning are synchronous, so very large documents can temporarily pause the tab.

JSON minification only needs to remove insignificant whitespace

RFC 8259 permits only space, horizontal tab, line feed, and carriage return as JSON whitespace around structural tokens. Once syntax is valid, removing those four characters outside strings is enough to compact the text; keys, strings, numbers, and member order do not need to change.

The input is validated first. A small scanner then removes only those four whitespace characters while it is outside a quoted string. That narrow pass avoids imposing a second serialization policy on already-valid JSON.

Whitespace outside strings can go; whitespace inside strings cannot

Before
{
  "city": "Pune",
  "name": "Sneha  Sonawane"
}

After
{"city":"Pune","name":"Sneha  Sonawane"}

Formatting whitespace between tokens is removable. The two spaces in the name string are part of the actual string and remain exactly as written. The same rule protects escape sequences and line-break escapes inside JSON strings.

Why parse-and-stringify is unnecessary for minification

Parse-and-stringify creates compact JSON, but it does so by constructing JavaScript values and then serializing those values again. Duplicate object names can collapse to one value. Very large numbers can lose precision. Numeric spelling such as exponent notation can be rewritten.

For minification, none of that rewriting is necessary. Removing whitespace from already-valid source tokens gives you compact text while leaving those diagnostic clues visible.

Minification reduces source bytes

Pretty indentation can add a noticeable amount of text to a large payload. Removing it reduces the uncompressed representation stored or transmitted.

Compression attacks repeated patterns too

gzip and Brotli encode repeated byte patterns, not just formatting whitespace. A minified response can still shrink substantially again when HTTP compression is enabled.

Minification Can Make Debugging More Expensive Than the Bytes It Saves

One-line JSON is efficient for machines but unpleasant in a log file, code review, incident ticket, or browser console. Keep readable source in repositories and operational tooling unless compact text has a real benefit. Readable indentation can be restored later, so keep the representation that fits the place where the payload lives.

Whitespace Changes Bytes Even When It Does Not Change the JSON Values

If a checksum, digital signature, cache key, HMAC, or test fixture is calculated over the literal JSON bytes, minification changes that byte sequence. Two JSON texts can represent equivalent values and still produce different hashes because their whitespace differs.

Do not minify a signed payload after the signature was created unless the signing protocol explicitly defines a canonical representation and you follow that exact procedure.

Smaller Text Does Not Fix Duplicate Names or Numeric Interoperability

The minifier reports duplicate member names and risky numeric tokens because those issues survive whitespace removal. If the next system keeps a different duplicate or rounds an identifier, the fact that the payload is now compact does not make it safer.

Treat those findings as source-data problems to resolve before relying on the payload across languages, runtimes, or APIs.