Guide
How to Validate JSON and Fix Common Syntax Errors
Validating JSON means checking that it follows the format's grammar so a parser will accept it. When JSON is invalid, the fix is usually small once you know what the parser is complaining about. This guide walks through the common errors and how to read them.
What validation checks
A JSON validator runs your text through the same kind of parser your code uses. If the parser reaches the end without a complaint, the JSON is valid. If it hits something that breaks the grammar, it stops and reports where. Validation is about syntax, not meaning. A validator confirms the JSON is well-formed, not that it has the fields your app expects. Checking for required fields and types is the job of a schema, which is a separate step.
Trailing commas
This is the single most common error. A comma is a separator, so it only belongs between items. A comma after the last item is invalid.
{
"name": "Ada",
"age": 36,
}The comma after 36 has nothing after it. Remove it and the object is valid. The same rule applies to arrays: [1, 2, 3,] is invalid, [1, 2, 3] is fine.
Single quotes and unquoted keys
JSON only accepts double quotes. Single quotes come from copying JavaScript or Python literals into a JSON context.
{ 'name': 'Ada' } // invalid
{ "name": "Ada" } // validUnquoted keys are the same story. { name: "Ada" } is a valid object in code but not valid JSON. Every key needs double quotes.
Unescaped characters inside strings
Some characters have to be escaped with a backslash inside a JSON string. The two that come up most are double quotes and backslashes themselves. A raw double quote ends the string early and confuses the parser.
{ "path": "C:\Users\ada" }
{ "quote": "She said \"hi\"" }Literal newlines inside a string are also invalid. Use \n instead of pressing enter inside the quotes.
Mismatched or missing brackets
Every opening brace or bracket needs a matching close. When a payload is long, it is easy to drop one. The parser usually reports an unexpected end of input or an unexpected token, and the position it gives you is where it noticed the problem, which may be after the real mistake.
Formatting the JSON first helps here. Once it is indented, an unclosed object stands out because the indentation never returns to the left margin.
How to read a parser error
Most errors give you a message and a position, like "Unexpected token } at line 5". Two habits make these easier to act on:
- Look at the character just before the reported position, not only at it. A missing comma is reported at the next token.
- Format the JSON before hunting. Structure makes trailing commas, unclosed brackets, and stray quotes visible.
Pasting the JSON into the formatter and validator does both at once. It points to the spot and shows the indented structure so the fix is quick.
FAQ
What is the difference between validating and formatting JSON?
Validating checks that the JSON follows the grammar and will parse. Formatting adds indentation to make it readable. A good formatter does both, since it has to parse the JSON before it can indent it.
Does valid JSON mean my data is correct?
No. Valid JSON is well-formed syntax. Checking that the data has the right fields and types is what a JSON Schema does, which is a separate step.
Why does the error point to the wrong place?
Parsers report where they noticed the problem, which is often the token after the real mistake. A missing comma, for example, is flagged at the start of the next item. Look just before the reported position.