Why JSON Needs a Strict Format (and What Breaks Without One)
The first time JSON rejects your data over a trailing comma, the rules feel petty. Double quotes only? No comments? No NaN? Surely a parser could just figure out what you meant. But the strictness is not an oversight — it is the entire reason JSON is trustworthy. This article explains what those rules buy you, and what goes wrong in formats that relax them.
One grammar, every language
JSON's promise is that the same bytes mean the same data in every programming language. A document written by a Python service must parse identically in JavaScript, Go, Rust, Java and a dozen others. That only works if there is exactly one way to read any valid document — no dialects, no "this parser is a bit more lenient" surprises.
Strictness is how you get that. A small, rigid grammar has no ambiguous cases to resolve, so two correct parsers can never disagree. The moment you allow optional extras — comments, trailing commas, unquoted keys — you create corners where implementations differ, and cross-language data exchange stops being reliable.
The rules, and the reasoning
Keys and strings must use double quotes
JSON allows only double quotes, never single quotes, and keys are always quoted:
{ "city": "Cairo" } ✓ valid
{ 'city': 'Cairo' } ✗ single quotes
{ city: "Cairo" } ✗ unquoted keyOne quoting style means the parser never has to guess where a string starts or ends. Unquoted keys, allowed in JavaScript source, are ambiguous the moment a key contains a space or a reserved word — so JSON simply bans them.
No trailing commas
A comma separates items; it cannot dangle after the last one:
[1, 2, 3] ✓ valid
[1, 2, 3,] ✗ trailing commaThis is the single most common JSON error. Many languages tolerate trailing commas in their own source, so the habit carries over — but in JSON a trailing comma implies a missing final element, which is ambiguous, so it is rejected outright.
No comments
JSON has no comment syntax at all. Douglas Crockford, who specified JSON, removed comments deliberately: people were using them to carry parsing directives, which broke interoperability. If you need to annotate JSON, add a normal field like "_comment": "...".
Numbers and special values are constrained
Numbers follow one decimal grammar — no leading zeros, no hex, no + prefix. And there is no NaN, Infinity, or undefined, because those have no agreed cross-language representation. The only literals are true, false and null.
What "lenient" formats cost you
Formats like JSON5 and HJSON deliberately relax these rules — they add comments, trailing commas and unquoted keys for hand-editing comfort. That is genuinely nicer to write, and fine for a local config file. But the data is no longer plain JSON: a standard JSON.parse will reject it, so you have taken on a special parser and given up universal compatibility. The trade is convenience now for interoperability later — usually the wrong trade for anything that crosses a network.
Not sure why a file is being rejected? Paste it in and the formatter points to the exact line and column that breaks the rules.
Validate your JSONStrictness is a feature
Every JSON rule trades a little writing comfort for a lot of reading certainty. Because the grammar is tiny and rigid, a JSON document is self-contained and unambiguous: anyone, in any language, can parse it the same way without negotiation. That reliability is exactly why JSON became the default for APIs and configuration. To turn these rules into a practical checklist, read JSON formatting rules and the errors that break parsers.