JSON Formatter and Validator

Every JSON tool will tell you a document is invalid. Very few will tell you where. This one reads the text with its own scanner rather than handing it to the browser, so when something is wrong you get a line and a column and a sentence about what the grammar expected there — not the word "unexpected" and a character offset you then have to count to. When the document is valid it is re-indented, or squeezed onto one line, with the order of your keys and the exact digits of your numbers left alone. Nothing you paste is uploaded; the whole thing runs in this page.

How it is calculated

JSON-text = ws value ws — whitespace between tokens carries no meaning

Formatting JSON is legal precisely because the grammar treats the space between the six structural characters as insignificant. Indenting adds that space back at one level per depth of nesting; minifying removes all of it. Nothing inside a string or a number is touched by either, which is why the spaces in a sentence survive and a trailing zero on a decimal survives with them.

Source: RFC 8259 section 2 — the JSON grammar: "Insignificant whitespace is allowed before or after any of the six structural characters", with ws defined as space, horizontal tab, line feed and carriage return

Questions people ask

Does formatting change the order of my keys?

No. The properties come out in the order you wrote them, including keys that look like numbers, which a round trip through a JavaScript object would silently reorder. Be aware, though, that the specification says an object is an unordered collection of name/value pairs, and that parsing libraries have been observed to differ over whether they expose member order at all. Every implementation you are likely to meet keeps insertion order, but nothing entitles you to rely on it.

Will my numbers survive exactly as I wrote them?

Yes. A number is carried through as the text you typed rather than converted to a floating point value and printed back, so -122.026020 keeps its trailing zero, 1E400 stays 1E400, and an integer too large for a double is not rounded on the way past. That is a deliberate difference from tools built on parse-then-stringify, which quietly rewrite all three.

Why does it reject a trailing comma when my editor accepts it?

Because JSON has no trailing comma and never has. The grammar puts a comma between two members and nowhere else. JSON5, JSONC and the tsconfig dialect all allow one, which is why the habit spreads, but a strict parser at the other end of a request will refuse the document.

What counts as a column?

Characters, counted from one, starting again at every line break. A tab counts as a single column rather than jumping to the next tab stop, so a position may sit slightly left of where your editor draws it in a tab-indented file. Both a lone carriage return and a carriage return with a line feed start a new line.

What happens to a property that appears twice?

Both copies are kept and shown back to you, and the page says which name was repeated. The specification says names within an object should be unique and warns that behaviour is unpredictable when they are not — some implementations keep the last, some fail, some keep everything. Silently dropping one of them here would hide the very thing worth seeing.

Is there a limit on what it will read?

Nesting stops at two hundred levels. The specification explicitly allows an implementation to set limits on depth, and the alternative to a stated limit is a page that runs out of stack and dies without saying why. Length is limited only by your machine.

Related tools