JSON Formatter and Validator

How to use the JSON formatter and validator

Paste on the left and the formatted document appears on the right, updated on every keystroke. Under it the same document is drawn as a collapsible tree, so a payload too long to scroll can be opened branch by branch. The panel then reports the nesting depth, the number of keys, how many objects and arrays there are, the minified size, and the bytes minifying would save.

Depth is the figure people underestimate. A response that reads as flat often nests four or five levels once you count every wrapper object, and deep nesting is what makes a payload hard to consume. Each array or object opens one more level, while a string, a number, a boolean and null open none.

Those three figures are the same document formatted three ways, and they answer a common argument. Pretty printing is not free, but the cost is whitespace and whitespace compresses to almost nothing. Once the response is gzipped or Brotli compressed the difference between the four versions is close to noise.

Sorting keys is the underrated switch. JSON objects have no defined order, so two servers can send the same data in different sequences and produce a diff full of moved lines. Sorting recursively before comparing collapses that noise, and it makes a payload easier to scan when you are looking for a field by name.

Nothing you paste leaves your browser. Parsing, formatting and measuring all happen on this page, with no upload, no logging, and nothing written into the page URL. Real API responses carry real customer data, and this tool is built so that pasting one here does not become a disclosure.

What JSON forbids that JavaScript allows

JSON started as a subset of JavaScript and stayed small on purpose. The grammar fits on one page, which is why there is a parser for it in every language. Everything convenient that JavaScript added afterwards, and everything a developer reaches for out of habit, is outside that grammar.

• No comments of either kind, which is the most common complaint about the format.
• No trailing comma after the last element of an array or the last member of an object.
• Strings use double quotes only, and every key must be quoted.
• No NaN, no Infinity, no undefined, and no leading zero on a number.
• A number needs a digit on both sides of the point, so .5 and 5. are both invalid.

The formats that relax those rules are real but separate. JSONC adds comments and is what editors use for configuration files. JSON5 adds comments, trailing commas, unquoted keys, single-quoted strings and hexadecimal numbers. Neither is JSON, and a strict parser at the other end of an API will reject both without apology.

The practical rule is to know which one you are writing. A configuration file your own tooling reads can be JSONC. Anything crossing a network boundary should be plain JSON, because you do not control the parser on the other side and the tolerant behaviour you are relying on is not in the specification.

The two failures that do not raise an error

A syntax error is the easy case, because something tells you. The two problems worth learning are the ones where the parser succeeds, hands you a value, and never mentions that the value is not what the sender wrote.

Duplicate keys matter most where documents are merged or generated by templating, because that is where the same key gets emitted twice without anyone intending it. RFC 8259 calls the behaviour undefined and warns that implementations differ, so a payload that works against one server can behave differently against another.

The number problem is bigger and more common. Database identifiers, snowflake IDs and timestamps in nanoseconds all routinely exceed 2^53 − 1, and every one of them loses its last digits in a JavaScript parser. The only real fix is at the source: send the value as a string and parse it deliberately.

The formula, worked line by line

There is no arithmetic in formatting, only counting, so the definitions matter more than any calculation. Depth, keys and size are the three figures this page reports, and each of them is defined below exactly as the tool computes it rather than as a rule of thumb.

The error location is the one genuine computation. A parser reports a character offset into the document, which is useless to a person reading 400 lines. Turning that offset into a line and a column is a matter of counting the newlines before it, and that is the whole trick.

depth = deepest nesting of arrays and objects, a plain value is 0
keys = every object key at every level, after duplicates collapse
bytes saved = input bytes − minified bytes
error line = 1 + the number of newlines before the offending character
error column = offset − start of that line + 1

Depth counts containers, not values. A single number is depth 0, an empty object is depth 1, and an object holding an object holding an object is depth 3. That last one is the sample above, whose limits object contains a depth object, and it is why the figure is a useful proxy for how awkward a payload will be to consume.

Byte counts here are UTF-8 bytes rather than characters, because that is what a network and a size limit actually measure. A document full of non-Latin text is larger than its character count suggests, and an emoji in a string is four bytes even though it looks like one character on screen.

Minification saves whitespace and nothing else, so its value depends entirely on whether the response is compressed. Over a gzipped or Brotli connection the saving shrinks to very little, because repeated runs of spaces are exactly what a compressor removes best. Uncompressed, in a log line or an embedded string, the figures above are the real ones.

Questions people ask