Validation runs the document through the browser's own JSON.parse — the strictest widely deployed RFC 8259 parser — as you type. Valid input shows a green status with line and byte counts; invalid input shows the parser's message with the exact line and column of the first error, and the offending line is highlighted in the gutter.
One number explains most validation sessions: a JSON parser reports exactly one error per run — the first one — because after an illegal token the rest of the document is unparseable by definition. Five mistakes cause nearly all failures: trailing commas, single quotes, unquoted keys, comments, and raw control characters in strings; all five are legal JavaScript and illegal JSON, which is why hand-written JSON fails so often while serializer output never does.
Formatted JSON will appear here.
When the status bar shows something like “Expected double-quoted property name at line 5, column 1”, look at that position and one token backwards — parsers report where they gave up, which is just after the real mistake. Fix it, and the next error (if any) is reported in turn. An error at line 1, column 1 with an apparently fine document usually means an invisible character: a UTF-8 BOM or a pasted smart quote.
Validate when an API rejects your payload, a config fails to load, or a deploy errors with “Unexpected token” — and before committing any hand-edited JSON file.
This page is a focused view of theJSON Formatter & Validator, which has the full set of options.
The usual suspects: trailing commas, single quotes instead of double quotes, unquoted keys, comments, and literal newlines inside strings. RFC 8259 allows none of these, even though JavaScript object literals allow most.
Parsers report where they gave up, which is at or just after the real mistake. A missing comma on line 4 is often reported at the start of line 5, where the parser met an unexpected token.
No — this checks syntax, not shape. It answers “is this parseable JSON?”, not “does this JSON match my schema?”.