Free Online JSON Minifier

Under RFC 8259, the JSON grammar treats four characters — space, horizontal tab, line feed, and carriage return — as insignificant whitespace when they sit between tokens. JSON Copilot minifies by parsing the document and re-serializing it with no whitespace between tokens: no indentation, no space after colons or commas, and no newlines separating properties. The result is compact, single-line JSON that parses to the same value your input did.

Whitespace inside a string is significant and is preserved. If a value contains a name like Ada Lovelace, the space between the words stays, because it is part of the data rather than the formatting. Escape sequences, Unicode characters, and newlines written as \n inside a string keep their meaning as well — the string values you get back are exactly the ones you put in.

Because the output is re-serialized rather than a raw character-for-character whitespace strip, a few things are made canonical. Numbers lose redundant formatting — 1.0 becomes 1, 1e3 becomes 1000, and trailing zeros disappear — duplicate keys collapse to their last value, and integer-like keys are emitted in ascending numeric order. None of this changes what the JSON means, since the spec assigns no significance to number spelling, key order, or repeated keys. It is still far safer than minifying JavaScript or CSS, where a tool may rename identifiers or drop rules that change behavior.

Minifying and gzip solve overlapping but distinct problems. Minifying works on the source text, removing whitespace before the payload is ever stored or sent. Gzip and Brotli are transport-level compressors that a web server applies on the fly, negotiated through the Accept-Encoding and Content-Encoding headers. One shrinks the characters; the other compresses the bytes.

Because gzip already models repeated runs of spaces and newlines efficiently, minifying on top of compression yields a smaller extra win than the raw byte numbers suggest — often only a few percent on the wire. The saving is still real, and it shows up in places compression does not reach: the size held in memory, the bytes written to a database column or localStorage, and the cost of parsing, since the parser has fewer characters to scan.

The practical rule is to do both. Minify JSON that you ship, and make sure gzip or Brotli is enabled on your API responses and static assets. For payloads that never touch a compressing transport — a message-queue body, a signed token, an embedded data attribute — minifying is often the only size lever you have, so it matters most there.

Minify anything that travels or is stored at scale: API responses, WebSocket frames, message-broker payloads, JSON embedded in HTML data attributes, and values you push into localStorage or a size-limited cache. In those cases every byte is multiplied by traffic or quota, and no human reads the raw text, so the whitespace is pure overhead.

Keep JSON formatted when a person reads or edits it. Configuration files such as package.json, tsconfig.json, or a CI workflow belong in version control, where indentation and line breaks produce clean, line-by-line diffs during code review. Minifying them collapses everything onto one line, so a one-character change looks like the whole file was rewritten. Logs you grep and fixtures you eyeball are the same story: readability beats a handful of saved bytes.

The common pattern is to separate source from output. You author and commit formatted JSON, then let a build step or your API layer minify at the moment of shipping. That keeps your repository reviewable while the wire stays lean — and because minifying preserves the value, the formatted and minified copies carry the same data.

At the value level, yes. Parse the pretty version and the minified version and you get deeply equal values. Formally, JSON.parse on the minified string produces the same object as JSON.parse on the formatted string, which is why you can move between the two forms freely. JSON Copilot re-expands any minified document with a single Format click.

Two nuances are worth knowing. First, because the minifier re-serializes through the JSON number type, values are made canonical: 1.0 becomes 1, 1e3 becomes 1000, and duplicate keys collapse to their last value. The parsed data is unchanged, but the text is canonical rather than a copy of your original spelling. Second, JSON numbers are IEEE 754 doubles here, so an integer with more than about 15 to 17 significant digits — a 64-bit ID sent as a bare number, say — can lose precision on the round trip. If you carry such values, keep them as strings so no re-serialization step can round them.

It validates first, too. Genuinely broken input, or JSON5 extras like comments and trailing commas that are not valid JSON, are flagged with a line-level error before anything is minified — so you never ship output that fails to parse. Fix the reported line, minify again, and the result round-trips to the same value.