DevNex

JSON Minifier

Strip whitespace and see the bytes saved.

Private · Runs entirely in your browser

What minifying removes, and what it cannot

JSON allows whitespace between tokens and ignores it entirely. Minifying deletes all of it: the indentation, the line breaks, and the space after every colon and comma. What is left is the same document with nothing optional in it.

What it does not touch is whitespace inside a string, because that is data. In {"note": "two spaces"} the double space between the words survives; the space after the colon does not. Any tool that removes the first one is broken, and this is worth knowing because a naive regex-based minifier does exactly that.

How to use it

  1. Paste JSON on the left. The minified version appears as you type.
  2. Read the four numbers: original size, minified size, bytes saved, and the percentage.
  3. Copy the result or download it as a .json file.

All four sizes are UTF-8 byte counts rather than character counts, because bytes are what a payload actually costs. The difference is not academic: an accented character costs two bytes, an emoji four, and a document full of names in a non-Latin script can be half again as large as its character count suggests.

When minifying is worth doing

Less often than you would think, and the honest reason is compression. Gzip and Brotli handle repeated whitespace extremely well, so once a response is compressed the difference between formatted and minified JSON is frequently a couple of percent. If your API already sends Content-Encoding: gzip, minifying is close to free but also close to pointless.

Where it genuinely matters is anywhere compression is not in play:

  • Stored data. A JSON blob in a database column, or in localStorage, where the browser quota is measured in megabytes and counted uncompressed.
  • Embedded payloads. JSON inside a URL, a QR code, or a header, all of which have hard length limits.
  • Message-based transports. Queues and brokers that bill or cap by message size, where every message pays the whitespace individually.
  • Anything at very high volume. Two percent of a large enough number is still a real number.

Worked example

The sample on this page is a small metrics document, indented with two spaces. Minified, it loses roughly a third of its bytes: most of that is indentation on the deeply nested samples arrays, where the values are short numbers and the whitespace around each one is a large fraction of the line.

Take the same document and replace the numbers with long strings and the saving shrinks sharply, because the whitespace stays the same size while the content grows. This is why the tool reports the numbers for your input instead of quoting a typical figure.

Important notes

  • Minified JSON is much harder to read. Keep the formatted version in your repository and minify on the way out, not the other way round.
  • The output is always valid JSON, because it is produced by parsing your input and writing it back. If parsing fails you get an explanation instead of partial output.
  • Duplicate keys collapse to the last occurrence, the same as they would in any parser. The JSON Validator reports them if you want to know first.

To go the other direction and make a payload readable, use the JSON Formatter.

Privacy

Minifying happens in your browser. Nothing is uploaded, and there is no server endpoint behind this page for a payload to reach.

Questions

Is minifying worth it if the response is already compressed?

Usually not much. Gzip and Brotli are very good at repeated whitespace, so a compressed response of minified JSON is often within a couple of percent of the compressed formatted version. Minifying matters where compression is not in play: data stored in a database column, embedded in a URL or a QR code, kept in localStorage, or pushed over a protocol you do not control.

Can minifying break my data?

The values cannot change. Only whitespace between tokens is removed, and whitespace inside a string is part of the string, so it is kept. The one thing that is not preserved is a duplicate key: it collapses to the last occurrence, which is what any parser would do with it anyway. The JSON Validator will tell you if your document has any before you find out the hard way.

Why is the percentage lower than I expected?

The saving comes from indentation and line breaks, so it depends entirely on how deeply the document nests and how short its values are. A deeply nested file of small numbers can lose more than half its size; a flat object holding long strings might lose two percent. The numbers shown are measured on your actual input rather than estimated.