JSON validator
Paste JSON and get each problem named on the line it occurs, in plain English — not a byte offset from wherever the parser happened to stop.
Better errors than your parser gives you
Every JSON parser reports the position where it gave up. That is almost never the position where you made the mistake — a missing closing brace on line 4 is reported at the end of the file. This checker scans the whole document first and names each problem in the place it occurs.
| What a parser says | What this says |
|---|---|
| Unexpected token } at position 247 | Line 12 — Trailing comma before }, valid in JavaScript, not in JSON. |
| Unexpected token ' at position 4 | Line 2 — Single quotes are not valid in JSON; strings must use double quotes. |
| Unexpected end of JSON input | Line 1 — { opened on line 1 is never closed. |
| Unexpected token N at position 88 | Line 6 — None is not a JSON value. Did you mean null? That looks like Python output. |
Everything it checks
- Bracket balance — every
{{and[reported at the line it opened on, not where the parser noticed. - Mismatched brackets — a
{{closed by a]. - Trailing commas before a closing bracket.
- Single-quoted strings anywhere in the document.
- Unquoted object keys.
- Comments, both
//and/* */. - Non-JSON literals —
NaN,Infinity,undefined, and the Python trioNone,True,False. - Unterminated strings — a quote that is never closed.
- The parser's own verdict, with the position translated into a line and column.
When it comes back clean, the formatted document is in the right-hand panel ready to copy.
Structure, not schema
This checks that your JSON is syntactically valid. It does not check that it is the right
JSON — that the price field is a number, that email is present, that
status is one of three allowed values. That is schema validation, and the standard for it is
JSON Schema.
The two jobs are separate and you want both. Syntax first, because nothing else can run until the document parses. Then schema, in your application or CI, using a library such as Ajv for JavaScript, jsonschema for Python, or the validator built into your API framework.
Reading the results
Work top to bottom. One unclosed bracket early in a document changes how everything after it is interpreted, so a single real mistake often produces several complaints. Fix the first one, run it again, and most of the rest usually disappear.
Line numbers refer to your original input, not the formatted output, so you can jump straight to the line in your editor.
Questions about this tool
Is this the same as JSON Schema validation?
No. This checks syntax — whether the document parses at all. JSON Schema checks meaning: required fields, types, allowed values, string formats. You need syntax to pass before schema validation can even run.
It reports a problem my editor does not. Who is right?
Check what the editor is actually parsing it as. Many editors treat .json files as JSONC — JSON with comments — because that is what VS Code settings files use. JSONC allows comments and trailing commas; strict JSON does not. If the file is going to a strict parser, this tool is the one telling you the truth.
Can I check JSON with comments deliberately?
The comments will be flagged, because they are not valid JSON. If you are working with JSONC or JSON5 on purpose, that flag is a note rather than an error — everything else the checker reports still applies.
Does it check for duplicate keys?
Not yet. Duplicate keys are technically allowed by the JSON specification, and every parser keeps the last one, so they are a silent bug rather than a syntax error. It is on the list.
Related tools
Learn the why, not just the how
Longer reading on formatting, indentation and minification.