JSON Formatter & Validator

How this works

Both outputs run the text through a real JSON parse and then re-serialise it: formatted with two-space indentation, minified with no whitespace at all. Because the parse is real rather than a tidy-up of the characters, anything that comes back is guaranteed to be valid JSON. That is also where the validation comes from, and it is specific. If the input does not parse, both boxes show the parser's own message - something like 'Invalid JSON — Expected double-quoted property name in JSON at position 7 (line 1 column 8)'. You get the position, and usually a line and column, rather than a bare failure. Read those messages knowing what they are. The parser reports what it EXPECTED to find, not what you did wrong, and the position is where it gave up - which is typically just after the actual mistake rather than on it. A trailing comma reports as an expected property name at the character following the comma. Once you know that, the message points straight at the problem. The usual culprits, in rough order of how often they turn up: a trailing comma after the last item, single quotes instead of double, unquoted keys, a stray comment, and an unescaped line break inside a string. JSON is deliberately strict about all five, and several of them are legal in JavaScript, which is why they slip through. Minifying never changes the DATA - formatted and minified parse to exactly the same value, so the minified form is safe to paste anywhere the formatted one would have worked. It is not purely a whitespace strip, though: like the formatter it re-serialises, so numbers come back in canonical form (see below). Whitespace INSIDE a string is left alone, because that is data rather than formatting. Numbers are re-serialised by the JSON parser, so they come back in canonical form. A value written as 1.50 comes back as 1.5 and 1e3 comes back as 1000 - the same number, spelled the way JSON writes it. Key ORDER is preserved. Nothing is transmitted. The parse happens in your own browser, which is worth stating plainly given what people paste into JSON tools: production API responses, config files and tokens.

Common questions

It says 'Invalid JSON' — how do I read the message?

The message is the JavaScript parser's own, and it tells you two things: what it EXPECTED to find, and the position where it gave up. Both take a little translating. A trailing comma, for instance, reports as 'Expected double-quoted property name' at the character just after the comma - because after a comma the parser is looking for another key. The position is usually just PAST the real mistake rather than on it, so look at the character before it.

What usually breaks it?

In rough order: a trailing comma after the last item in an object or array, single quotes instead of double quotes, keys left unquoted, a comment, and a raw line break inside a string. JSON forbids all five, and several of them are perfectly legal in JavaScript - which is exactly why they get typed by accident. Trailing commas alone probably account for more broken JSON than everything else combined.

Does minifying change my data?

Not the data, no - the formatted and minified outputs parse to exactly the same value, so you can paste either wherever the other would have worked. It is not a pure whitespace strip though: minifying re-serialises through the parser just as formatting does, so numbers come back in canonical form (1.50 becomes 1.5). Whitespace inside a string is left alone, because that is data rather than formatting.

Why did my number change?

It did not change value, only spelling. The parser re-serialises numbers in canonical JSON form, so 1.50 comes back as 1.5 and 1e3 comes back as 1000. These are the same number written the way JSON writes it. If the exact original text matters - a version string, an ID with leading zeros - it should have been a string rather than a number in the first place.

Is my JSON sent anywhere?

No. The parse happens in your own browser and nothing is uploaded or stored. This is worth stating plainly because of what actually gets pasted into JSON tools: production API responses, configuration files, and occasionally credentials that were sitting in them.

Does it keep my key order?

Yes - keys come back in the order they appeared. JSON objects are formally unordered and most parsers preserve insertion order in practice, which this relies on. If your consumer genuinely depends on key order, that is worth knowing about your consumer, because the specification does not guarantee it.

More encoding & developer tools