How to Validate JSON and Fix Common Syntax Errors

Updated 2026-08-31 · 3 min read

What makes JSON valid

JSON is a strict subset of JavaScript. Keys must be double-quoted strings, values may only be strings, numbers, booleans, null, arrays or objects, and nothing else — no functions, no undefined, no comments and no trailing commas.

The 5 errors that cause most failures

• Trailing comma — {"a":1,} is invalid. Remove the last comma.
• Single quotes — {'a':1} must be {"a":1}.
• Unquoted keys — {a:1} is a JavaScript object literal, not JSON.
• Comments — // note and /* */ are not allowed; strip them or use JSON5 in your build step only.
• Unescaped characters — literal newlines, tabs and unescaped double quotes inside strings must be written as \n, \t and \".

Reading 'Unexpected token' messages

The parser reports the first position where the document stops being valid, which is usually one character after the real mistake. If the error points at a closing brace, look at the line above for a trailing comma or a missing value.

Validate and format it instantly

Paste your document into the JSON Formatter & Validator. It reports the exact error position, then beautifies with clean indentation or minifies for transport. Everything runs in your browser, so API payloads containing customer data are never uploaded.

A repeatable debugging workflow

When a payload fails to parse, resist the urge to eyeball it. Work through the same four steps every time and you will find the problem in under a minute:

• Parse it and read the reported character position — that is the first place the document became invalid, not necessarily where the mistake is.
• Look at the line above the reported position for a trailing comma or a missing value.
• If the file is large, bisect it: delete the second half, re-parse, and keep halving until the failure disappears.
• Once it parses, format it. A formatter's indentation makes an unbalanced brace obvious at a glance.

Invisible characters that break valid-looking JSON

Some failures survive careful reading because the offending characters do not render. A UTF-8 byte order mark (EF BB BF) written by Windows editors sits before the opening brace and makes every parser complain about position 0. Smart quotes pasted from a document editor look almost identical to straight quotes but are different code points. Non-breaking spaces copied from a web page are not valid JSON whitespace.

If a document looks perfect and still fails at the very start, retype the first brace, save the file as UTF-8 without BOM, and re-parse.

Numbers, precision and dates

JSON numbers have no defined precision. JavaScript parses them as 64-bit floats, so integer IDs beyond 9,007,199,254,740,991 silently lose their last digits — a real source of records mysteriously pointing at the wrong row. Send large IDs as strings.

NaN, Infinity and leading zeros are all invalid; a leading zero like 0123 is a syntax error rather than the octal you may expect. JSON also has no date type, so pick one convention — ISO 8601 strings such as 2026-08-31T14:00:00Z are readable and sort correctly, while Unix timestamps are compact and unambiguous.

Syntax validity is not data validity

A document can parse perfectly and still be wrong for your API: a missing required field, a string where a number belongs, or an enum value nobody supports. Syntax validation catches the first class of bug; schema validation catches the second.

In TypeScript, define a Zod schema and call schema.safeParse(JSON.parse(raw)) so parse errors and contract errors are handled separately. In other stacks, JSON Schema gives you the same guarantee and doubles as documentation for consumers of your API.

Formatting for humans versus for machines

Pretty-printed JSON with two-space indentation belongs in config files, fixtures, documentation and anything a person reviews in a diff. Minified JSON — no whitespace at all — belongs on the wire, where the saved bytes matter and gzip compresses it further.

Keys in a machine-generated file should be sorted deterministically. If your build writes JSON with keys in hash order, every commit produces a noisy diff and code review becomes useless.

Working with JSON safely at scale

Never validate production payloads by pasting them into an online service that uploads data — customer records, tokens and internal endpoints end up on a third-party server. Browser-based tools that parse locally avoid the problem entirely.

For files above a few megabytes, a streaming parser is the right tool; loading a 500 MB export into memory to check a comma will exhaust the process long before it reports an error.

Validating JSON in code

In JavaScript, wrap JSON.parse in a try/catch and log the error message — it contains the position. For contract-level validation (required fields, types, enums), use a schema validator such as Zod or JSON Schema instead of ad-hoc checks.

Frequently asked questions