Most "invalid JSON" errors come from the same handful of mistakes, usually because the JSON looks like valid JavaScript — which is a different, more permissive grammar. Here are the ones that come up constantly, what the error usually looks like, and the fix.
Trailing commas
{
"name": "Alice",
"role": "admin",
}That comma after "admin" is allowed in a JavaScript object literal, but JSON's grammar has no concept of a trailing comma — the parser expects either another key or the closing }, and sees a comma instead. Fix: delete the comma after the last item in any object or array.
Single quotes instead of double quotes
{'name': 'Alice'}JSON strings and keys must use double quotes — single quotes aren't valid JSON syntax at all, full stop. This one is easy to introduce by copy-pasting from JavaScript source code rather than an actual JSON file or API response.
Unquoted object keys
{name: "Alice"}Valid as a JavaScript object literal, invalid JSON — every key must be a quoted string. The error message here is often something like Unexpected token n in JSON at position 1, pointing right at the bare name.
Comments
{
// this is the user's display name
"name": "Alice"
}JSON has no comment syntax whatsoever — not //, not /* */. If you're editing a file with comments and it should be strict JSON (not JSON5 or JSONC, which some tools like TypeScript's tsconfig.json loosely support), the comments have to go.
Duplicate keys
{"status": "active", "status": "pending"}This one won't throw at all — it's technically valid JSON, and most parsers (including JSON.parse) silently keep only the last value. It's a common source of confusing bugs precisely because there's no error to point you at it; worth a manual check if a value seems to be silently different than what you typed.
An extra or missing closing bracket
Usually the result of editing nested structures by hand — deleting a block but leaving one of its brackets behind, or adding a new nested object without its matching close. The error position for these is often unhelpfully far from the actual mistake, since the parser doesn't realize anything's wrong until it runs out of expected input; this is the case where a tool that shows the exact line/column, rather than just a boolean, saves the most time.
Checking your own JSON before it breaks something downstream
Every one of these is easy to introduce by hand and easy to miss by eye, especially in a large payload. Our JSON Validator runs entirely in your browser and points at the exact line and column where parsing failed, so you can jump straight to the mistake instead of re-reading the whole document.