Find out exactly where your JSON breaks, and why.
Paste JSON to check it.
Your JSON is parsed in this tab and never sent anywhere.
Checks whether JSON is valid, and when it is not, says where and why. The failing line is shown in context with a caret under the exact column, because “unexpected token at position 447” is not something anyone can act on while looking at a file.
For the mistakes that account for most broken JSON, it names the cause outright: a trailing comma before a closing bracket, single quotes instead of double, an unquoted property name, a missing comma between values, or a document that simply ends early. All of those are legal JavaScript and illegal JSON, which is exactly why they slip through.
When the document does parse, you get its shape instead — how many keys, how deeply nested, what kinds of value it contains.
Deploys and builds reject malformed JSON with famously unhelpful messages. This points at the character.
Confirming a request body parses is faster than reading a 400 response and guessing which part the server disliked.
Hand-edited JSON goes wrong in a handful of predictable ways, and every one of them is named here rather than left for you to spot.
The shape summary — key count, nesting depth, what types are inside — tells you what you are dealing with before you start reading.
It is checked as you type. There is nothing to submit.
Valid, or the line and column of the first problem with the likely cause named where it can be worked out.
The surrounding lines are shown with a caret under the exact column, so you can see the problem in context rather than counting characters.
Edit in place; the verdict updates on every keystroke. To tidy the formatting as well, use the JSON Formatter.
Almost always one of five things: a trailing comma, single quotes, unquoted property names, a missing comma between values, or an unclosed bracket. Each is valid JavaScript, which is why they are so easy to write by accident.
No — neither is part of the JSON specification, so a document containing them is reported as an error rather than quietly accepted. Some parsers are lenient; relying on that makes the file non-portable.
Not yet. This validates syntax — whether the document is well-formed JSON at all — rather than whether it matches an expected structure.
The same parser, pointed the other way. The formatter exists to produce tidy output; this one exists to explain failure, so it shows the failing line in context and describes the document's shape when it succeeds.
No. It is parsed in this browser tab by the browser's own parser. That matters — the JSON developers most need to check is usually a production payload with real data in it.