JSON minifier

Whitespace between tokens is meaningless and whitespace inside a string is data. A minifier that removes every space it finds will turn a name, an address or a sentence stored as a value into something else, and the result is still valid JSON — so nothing downstream complains, and the corruption is discovered by a person reading it much later.

This one parses the document and prints it without indentation, which cannot make that mistake by construction. It is also why it refuses input that does not parse: there is no partial understanding to fall back on.

Formatted JSON is typically twenty to forty per cent whitespace, so the number here looks impressive. Over a network it mostly is not, because responses are compressed and gzip is extremely good at runs of spaces — the compressed difference between formatted and minified JSON is often under five per cent.

Where it does count is anywhere compression is not in play: a value in an environment variable, a column in a database, a single line in a log, a field with a hard length limit, a QR code. Those are the reasons this page exists, and in every one of them the raw byte count is the constraint.

A character count is what a text box gives you and it is the wrong measure. JSON travels as UTF-8, where an ASCII character takes one byte, an accented Latin or Cyrillic character two, most CJK three, and an emoji four. A document of a thousand Japanese characters is roughly three thousand bytes.

Every real limit — a header size, a column width, a message size on a queue — is in bytes. Measuring in characters means a document that fits by your count and is rejected by theirs, which is a confusing failure precisely because the number you checked was fine.

Do it for anything stored or transmitted where compression is absent and size is bounded. Do it for a payload you are about to paste into a form field, a CI variable or a Kubernetes secret. Do it for a document that has to be one line because something downstream reads line by line.

Do not do it to a file that lives in a repository. A minified config is a config nobody can review: every change touches the single line it consists of, so the diff shows the whole file and a reviewer sees nothing. The bytes saved are irrelevant next to that, and the build step that would minify it on the way out already exists.

Not much, and that is the point of knowing where the floor is. Minified JSON still spends bytes on quotation marks around every key, on the key names themselves repeated in every record of an array, and on the punctuation between them. For a list of a thousand objects with the same four fields, the field names are most of the file.

If minifying is not enough, the next steps are structural rather than cosmetic: shorter key names, an array of arrays with the field names stated once, or a format that is not JSON. That is a decision about the interface, not about whitespace, and it is worth recognising which of the two you are actually in.