JSON has become the default data format for nearly everything on the modern web — APIs, config files, data exports — and it's simple enough that most people pick up the basics in minutes. But "simple" and "forgiving" aren't the same thing, and JSON's strictness trips up more people than its apparent simplicity would suggest, usually in the form of a parser throwing an error on a file that looks perfectly reasonable at first glance.
Why JSON is strict on purpose
JSON was deliberately designed as a much simpler subset of JavaScript object syntax, specifically so that a JSON parser could be small, fast, and unambiguous. That design goal meant sacrificing a lot of the convenience features programmers are used to in actual JavaScript or other more forgiving formats — trailing commas, comments, single-quoted strings, unquoted keys. None of those are JSON syntax errors by accident; they were left out on purpose, because a stricter grammar is easier to parse reliably and consistently across every implementation, in every programming language, without ambiguity about how to interpret an edge case.
The trailing comma trap
This is probably the single most common JSON error, precisely because it's completely valid in the JavaScript syntax JSON superficially resembles. In JavaScript, you can write an array or object literal with a trailing comma after the last item and the language simply ignores it. JSON has no such tolerance — a comma after the final element in an array or the final property in an object is a hard syntax error, full stop. This trips people up constantly when hand-editing a JSON file, especially when adding or removing the last item in a list and forgetting to also remove the newly-trailing comma.
Comments don't exist in JSON, at all
Despite how useful a comment explaining a particular config value would be, the JSON specification has no comment syntax whatsoever — not //, not /* */, nothing. This is a deliberate omission from the original spec's author, and it surprises a lot of people coming from JavaScript or almost any programming language, where comments are taken for granted. If you need to document a JSON config file, the common workarounds are either a separate documentation file, a convention of using a specially-named "_comment" key with a string value (hacky but functional), or switching to a format that does support comments, like JSON5 or YAML, if the tooling you're working with accepts one of those instead.
Keys and strings must use double quotes, always
JSON requires double quotes around every string value and every object key — no exceptions, and no single quotes allowed, even though single-quoted strings are perfectly valid JavaScript. An object key like name written without any quotes at all is valid, convenient JavaScript object shorthand, but it's a syntax error in strict JSON, where every key must be a properly double-quoted string. This particular difference is a very common source of confusion specifically because JSON looks so much like a JavaScript object literal that it's easy to forget the two aren't actually interchangeable.
Numbers have their own quiet restrictions
JSON numbers can't have a leading zero before the decimal point (except for the number zero itself), can't be written as a hexadecimal literal, and can't include special values like NaN or Infinity, all of which are valid in actual JavaScript but rejected by strict JSON parsers. This rarely comes up in hand-written JSON, but it does show up when JSON is generated programmatically from a language that produces one of these special numeric values without special-casing it for JSON export first.
Why the strictness is actually a feature, not a flaw
It's tempting to read all of this as JSON being needlessly rigid, but the strictness is exactly what makes JSON reliably parseable the same way across every language and every implementation, with no ambiguity about how to handle an edge case differently. A more forgiving format has to make judgment calls about how to interpret unusual input, and different parsers can end up making those judgment calls differently, leading to data that parses fine in one system and fails in another — precisely the kind of inconsistency JSON's strict, unambiguous grammar was designed to avoid entirely.
Finding the actual problem in a broken file
When a JSON parser reports an error, the message often points to the position where the parser first got confused, which is sometimes a few characters after the actual mistake — a missing comma is reported at the position of the next token, not the missing comma itself, for instance. Running a suspect file through a dedicated validator that highlights the exact problem is usually faster than scanning by eye for something as easy to miss as one extra or missing comma. Our JSON formatter both validates and pretty-prints JSON, making structural issues easier to spot once the content is properly indented, and will flag the specific parsing problem if the input isn't valid JSON in the first place.
The short version
JSON's restrictions — no trailing commas, no comments, double quotes only, no special numeric values — all exist to keep the format small and unambiguous, not because anyone forgot to add convenience features. Knowing the specific list of "this looks fine but isn't valid JSON" patterns is usually enough to avoid the most common errors before they happen.