JSON Validator
Check JSON syntax against RFC 8259 and get the exact line and column of every error — with human-readable messages, not parser codes.
The most common JSON syntax errors
After a parse failure, the message tells you what the parser expected and the position tells you where it gave up. These six mistakes cause the vast majority of invalid JSON:
- Trailing commas —
{"a": 1,}. Legal in JavaScript, illegal in JSON. - Single quotes —
'name'instead of"name". JSON strings and keys must use double quotes. - Unquoted keys —
{name: "Ada"}. Every key needs double quotes. - Comments —
//and/* … */are not part of JSON (that is JSONC, a different format). - Special values —
NaN,Infinity,undefinedand Python'sTrue/Nonedon't exist in JSON. Use numbers,true/falseornull. - Unescaped characters — raw line breaks or quotes inside a string. They must be written
\nand\".
All six are exactly what the JSON Formatter'sRepair button fixes automatically — validate here, repair there, done.
RFC 8259 vs 7159 vs 4627 vs ECMA-404
| Standard | Year | Practical difference |
|---|---|---|
| RFC 8259 | 2017 | Current standard. Any JSON value allowed at the top level. UTF-8 required for interchange. |
| RFC 7159 | 2014 | Same grammar as 8259 for practical purposes. |
| RFC 4627 | 2006 | Original spec — top level must be an object or array. "hello" alone is invalid. |
| ECMA-404 | 2013 | The ECMA counterpart; same syntax as RFC 8259. |
Unless you maintain a legacy system that enforced RFC 4627, validate against RFC 8259. The selector exists because "is this valid JSON?" occasionally really does depend on who is asking.
Validation is the first gate, not the last
A JSON document can be perfectly valid and still wrong for your application — a missing field, a string where a number should be. Syntax validation catches the class of bug that breaks every consumer (the parser error); schema validation catches the rest. If you need the second kind, a JSON Schema validator is the right tool — this page deliberately does one job fast and precisely.
Frequently asked questions
Why does the validator show a line and column?
Because "invalid JSON" alone is useless in a 5,000-line payload. This validator reports the first offending token with its exact line and column, underlines it in the editor, and gives you a one-click jump to the spot. The messages are written for humans: instead of a bare parser code you get hints like "You may have a trailing comma before }".
What is the difference between the RFC options?
RFC 8259 is the current JSON standard and the right default. RFC 7159 is its direct predecessor with essentially the same grammar. RFC 4627, the original 2006 spec, additionally required the top-level value to be an object or array — a bare "hello" or 42 fails under 4627 but passes under the newer standards. ECMA-404 defines the same syntax as RFC 8259.
Does valid JSON mean my data is correct?
Syntactically, yes — semantically, no. The validator confirms the document parses: quotes, commas, braces and escapes are right. It does not check that "age" is a number or that required fields exist; that is the job of a JSON Schema. Syntax validation is still the essential first gate, because a parse error breaks every consumer downstream.
Why does my JSON work in JavaScript but fail here?
JavaScript object literals are more permissive than JSON: they allow single quotes, unquoted keys, trailing commas, comments and values like undefined or NaN. None of those are legal JSON. Paste the data into the JSON Formatter and press Repair to convert the usual JavaScript-isms into strict JSON automatically.
Is my data sent anywhere when I validate it?
No. Validation runs entirely in your browser — the page works even offline once loaded. Nothing is uploaded, logged or stored on a server, so validating confidential payloads is safe.