How to validate JSON
- Paste the JSON you want to check into the box above.
- Read the status box. It says Valid or Invalid immediately.
- If invalid, look at the report, which shows the failing line with a caret under the character.
- Fix the problem and watch the status change as you type.
- When valid, check the structure summary against what you expected.
What the validator reports
- A clear valid or invalid verdict with no ambiguity.
- The exact line and column of the first syntax error.
- The failing line printed with a caret pointing at the character.
- A plain-language explanation of what went wrong.
- Structure statistics when the document parses: keys, objects, arrays, depth.
- Live rechecking as you edit, so you see the moment it becomes valid.
Why JSON errors are so hard to find
The message a parser gives you is technically accurate and practically useless. "Unexpected token } in JSON at position 1847" tells you a character offset in a document that might be one enormous line. Nobody can count to 1847.
Worse, the reported position is usually where the parser noticed the problem, not where the problem is. A missing closing brace on line 12 is not detected until the parser reaches the end of the document and runs out of input, so it reports the last line. The real fault is a hundred lines earlier.
What this validator does differently
It converts the character offset into a line and column, prints the surrounding lines, and puts a caret under the exact character. That turns an abstract number into a place you can look at.
It also examines the characters around the failure rather than trusting the engine's wording, which varies between browsers and versions. A comma immediately before a closing brace is reported as a trailing comma whatever the engine called it, and a single quote near the failure is reported as a quoting problem.
The five errors that account for almost everything
- Trailing comma: after the last property or array item. Legal in JavaScript, illegal in JSON.
- Single quotes: JSON requires double quotes on both keys and string values.
- Unquoted keys:
{name: 1}is a JavaScript literal, not JSON. - Unclosed bracket: reported at the end of the document, not where it opened.
- Comments: JSON has no comment syntax at all.
Syntax validity is not correctness
This is a syntax checker. It confirms that a document is well-formed JSON. It cannot tell you whether the structure matches what an API expects, whether a required field is missing, or whether a value is the right type. That is schema validation, a separate discipline usually handled with JSON Schema.
The structure summary helps bridge the gap informally. If a response should contain twelve keys and the count says nine, something is missing regardless of the document being valid. If the nesting depth is far greater than you expected, the shape is probably not what you assumed.
A note on trailing commas specifically
This trips up more people than everything else combined, because modern JavaScript encourages them. A trailing comma produces cleaner diffs when adding a line. That habit carries into JSON files, where it is invalid. Some parsers accept them as an extension, which makes it worse: the file works locally and fails in production.
Once the document parses, the JSON formatter makes it readable and the JSON minifier compresses it for shipping. Nothing is uploaded at any stage, so payloads with credentials or personal data stay on your machine.
Validating JSON that arrives from somewhere else
Most broken JSON is not hand-written. It comes out of a template that concatenated strings without escaping them, a log line that truncated at a buffer boundary, or an API that returned an HTML error page with a JSON content type. Recognising which of those you have saves a lot of time.
A document that fails at the very first character is usually not JSON at all, paste the start of it and look. A document that fails partway through with everything before that point looking sane is usually truncated. A document with an unescaped quote in the middle of a string points at string concatenation somewhere upstream that never handled escaping. The line and column tell you which, and that tells you where to look in the code that produced it.