Common JSON validation errors
June 28, 2026 · 13 min read
JSON looks forgiving because JavaScript object literals are relaxed - trailing commas, comments, unquoted keys, and undefined slip into copy-pasted configs. Strict JSON parsers reject those extensions, which is why a file that “works in the browser console” fails in JSON.parse, Python json.loads, or your API gateway.
Validation errors cost the most time when they surface late: after deployment, in a partner’s webhook receiver, or inside a log pipeline that drops malformed lines. Learning the top failure modes lets you fix data at the edge with clear messages instead of generic “unexpected token” errors.
Strict syntax rules
Valid JSON has exactly two structural tokens for objects and arrays: curly braces and square brackets. Keys must be double-quoted strings. Strings use double quotes with mandatory escaping for control characters. No literal undefined, NaN, or Infinity - use null or quote them if your schema expects strings.
UTF-8 is the default encoding on the wire. BOM prefixes and non-UTF-8 bytes cause parsers to fail or misread characters. If you ingest files from Windows tools, scan for BOM and normalize newlines before validation.
Trailing commas
A trailing comma after the last element in an array or object is illegal in JSON but common in JavaScript and some config formats (JSON5, Hjson). Editors with “format on save” for JS often leave trailing commas that break strict validators.
Fix: remove the comma or run a strict formatter that targets JSON, not JavaScript. In generated JSON, teach your serializer library to emit standard JSON - never hand-concatenate brackets and commas for production payloads.
// Invalid: trailing comma
{ "items": [ 1, 2, 3, ], "ok": true, }
// Valid
{ "items": [ 1, 2, 3 ], "ok": true }Comments and single quotes
JSON does not allow // or /* */ comments. Tools that accept them are not JSON parsers - they are superset parsers. Do not store commented “JSON” in databases; strip comments at import time and save canonical JSON.
Single-quoted strings are likewise invalid. If you must ingest relaxed syntax from legacy systems, parse with a JSON5 library in a dedicated migration step, then emit strict JSON for everything downstream.
Numbers and special values
Leading zeros (01) are not allowed. Hex (0xFF) is not allowed. If you need big integers or exact decimals, represent them as strings and enforce types with JSON Schema.
Duplicate keys are another silent hazard: RFC 8259 says names should be unique, but parsers may last-key-wins. Never depend on duplicate-key behavior; dedupe at generation time.
Preventing bad JSON at source
Serialize with standard libraries, not template strings. Validate in CI with a strict parser and JSON Schema. For manual edits, use a schema-aware editor and a browser validator before commit.
At API boundaries, return 400 with parser position and a snippet of context. Logs that only say “invalid JSON” force hours of binary search through multi-megabyte bodies.
FAQ
- Why does JSON.parse fail on my config file?
- Config files often include comments, trailing commas, or unquoted keys. Convert to strict JSON or use a JSON5 parser in a controlled import step.
- Is NaN valid in JSON?
- No. Use null or omit the field, or encode the value as a string if your schema allows it.
- Are duplicate keys a syntax error?
- Syntactically the document may parse, but behavior is undefined. Treat duplicates as invalid in your pipeline.
- Can I validate JSON against a schema?
- Yes. Syntax validation ensures parseability; JSON Schema adds rules for required fields, types, and value constraints.