Validators6 min read
Invalid JSON is one of the most common causes of a broken API call or a failed config load, and the error messages parsers give are often cryptic. This guide covers the actual rules of the JSON grammar, the handful of mistakes that cause almost every error, and how to fix each one. You can paste any example into the JSON Formatter to see it validated in real time.
The rules of valid JSON
JSON is a strict format defined by RFC 8259. Knowing its small set of rules is enough to fix nearly every validation error you will meet.
- Strings and object keys must use double quotes — never single quotes.
- No trailing comma is allowed after the last item in an object or array.
- Keys must be quoted; bare identifiers are not valid.
- Allowed values are string, number, true, false, null, object, and array.
- No comments are permitted anywhere in the document.
- Numbers use a plain decimal form — no leading zeros, no NaN, no Infinity.
Validating vs formatting
Validating checks whether text conforms to the JSON grammar and reports any error. Formatting parses the JSON and re-prints it with clean indentation, so formatting always includes validation — if it cannot be formatted, it is not valid. A JSON Schema validator goes a step further, checking not just that the syntax is valid but that the data has the required fields and types.
Common errors and how to fix them
Most validation failures come from the same short list. Here is what each looks like and the fix.
| Problem | Fix |
|---|---|
| Trailing comma: {"a":1,} | Remove the comma after the last value |
| Single quotes: {'a':1} | Use double quotes: {"a":1} |
| Unquoted key: {a:1} | Quote the key: {"a":1} |
| Missing comma: {"a":1 "b":2} | Add a comma between items |
| Leading zero: {"n":007} | Write the number without leading zeros |
| Comment: // note | Remove it — JSON has no comments |
Reading a parser error
A message like 'Unexpected token } in JSON at position 14' names the character where parsing stopped, not always where the mistake is. The real cause is often a few characters earlier — a missing brace, an extra comma, or an unclosed string. Start at the reported position and scan backwards.
Formatting the document first helps: once it is indented, an unclosed bracket or a misplaced comma is far easier to see than in a single dense line.
Validating structure with a schema
Syntax validity is not the same as correctness. A document can be perfectly valid JSON and still be missing a required field or have a number where a string was expected. JSON Schema lets you describe the required shape — which fields must exist and what type each must be — and validate data against it, which is how APIs enforce their contracts.
{
"type": "object",
"required": ["id", "email"],
"properties": {
"id": { "type": "number" },
"email": { "type": "string" }
}
}Frequently asked questions
Does JSON allow comments?+
No. Standard JSON has no comment syntax. If you need comments in a config file, a format like YAML or JSON5 supports them, but they are invalid in strict JSON.
Why does my JSON say 'Unexpected token'?+
The parser hit a character it did not expect for valid JSON — most often a trailing comma, single quotes, an unquoted key, or a missing comma. The position it reports is where parsing stopped.
Can JSON keys be unquoted?+
No. Every key must be a double-quoted string. Unquoted keys are valid in JavaScript object literals but not in JSON.
What is the difference between JSON validation and JSON Schema validation?+
JSON validation checks the syntax is well-formed. JSON Schema validation additionally checks the data has the required fields and correct types defined by a schema.
Try it now
Put this into practice with the free, in-browser tools: