Most JSON syntax errors come from treating a .json file or an HTTP body like the object you would type in application code. JavaScript (and many linters) allow unquoted keys, single quotes, trailing commas, and comments. The JSON grammar does not. JSON.parse and every strict API client will reject those extras. The JSON Validator uses that same parser, so it fails in the same places.
This article is a map of the failures you will see again. It is not a how-to for one tool click. When you already have an error in hand, the parse-error solution is the practical checklist.
A comma after the last property or array item is legal in modern JavaScript and illegal in JSON. The parser usually points at the comma or at the following } / ]. Editors that auto-insert commas in TypeScript objects will happily write a broken package.json if you are not looking.
There is no “JSON5 mode” on this site. If you need comments and trailing commas as a human format, that is a different language. Convert to JSON before you ship the body.
Keys must be double-quoted strings. {name: "Ada"} and {'name': 'Ada'} both fail. Smart quotes from email or docs also fail because they are not U+0022. Copy from a slide deck is a frequent source.
Strings inside values follow the same rule. A SQL fragment or Magento path that contains unescaped quotes will break the surrounding JSON. Escape inner double quotes as \".
// and /* */ are not JSON. Neither is a PHP warning printed before the {, a BOM, or two JSON values glued together. An error at position 0 often means garbage before the first value, not a problem in the object you thought you pasted.
APIs that wrap JSON in a padding function (JSONP) or prepend )]}', as an XSSI defense are not something you can validate as raw JSON until you strip the prefix.
JSON strings allow a small escape set. \x41 is a JavaScript escape, not a JSON one. Lone surrogates and illegal UTF-8 produce failures that look mysterious until you inspect the bytes. Save the file as UTF-8 without a BOM unless your consumer requires one — and know that a BOM will shift every position in the error message.
Recognize the class of error, change the text, and confirm with the validator. If you then need to see nesting, use the JSON Formatter. If you need the first-token checklist, that is a solution page, not this article. The point of keeping them apart is that “what the mistakes are” and “what I click next” are different searches.
Style guides help more than another generic “what is JSON” intro. Ban trailing commas in committed .json files. Ban comments in anything a production parser will load. Generate fixtures from a real encoder instead of hand-typing them in a ticket. Most recurring JSON syntax errors disappear when humans stop authoring the bytes.
When a vendor sends illegal JSON, do not silently “fix” it in a client and forget. Log the raw body, reject it, and show the token. A client that accepts comments this week will break when you switch parsers next year. Strict JSON is the portable contract.
New developers hit the same five JSON syntax errors in their first month. Teaching the grammar once — quotes, commas, comments, escapes, prefixes — is cheaper than debugging each incident as a unique outage. Keep the examples short. Keep the validator bookmarked. Leave the philosophy for a later article.
Object literals allow syntax JSON does not: unquoted keys, single quotes, comments, and trailing commas.
Garbage before the first value: a BOM, a PHP notice, or a prefix. Strip it, then parse again.
Not in standard JSON. Some parsers accept JSON5 or JSONC. This site does not.
Paste it into the JSON Validator. Fix the first token. Format only after it is valid if you need to read it.
