Two things that feel like they should be allowed in JSON are not: comments, and a comma after the last item in an array or object. {"a": 1,} and // note are both invalid JSON.

Why the standard forbids them

JSON (RFC 8259) is deliberately a data-interchange format, not a configuration language. Its author left comments out on purpose, partly to keep parsers simple and partly because comments were being abused to carry parsing directives. Trailing commas are excluded for the same minimalism: the grammar says items are comma-separated, so a comma with nothing after it is a syntax error. A strict parser will reject both, and a good formatter will flag them.

The tolerant variants

The friction is that many places people write JSON accept more:

  • JSONC (JSON with Comments) adds // and /* */ comments. This is what powers editor settings files and tsconfig.json, which is why those accept comments even though they look like JSON.
  • JSON5 goes further: comments, trailing commas, unquoted object keys, single-quoted strings, hex numbers, and more. It is a superset aimed at hand-written config.

These are genuinely different formats that happen to look like JSON. The trap is portability: a config file with comments is fine in the tool that expects JSONC, and a hard error the moment another program parses it as strict JSON. The safe rule is to keep comments and trailing commas out of any JSON meant to be consumed by something you do not control, and to strip them (which a formatter can do) before sending JSON across a boundary.

The dialect your parser accepts is not the one you documented

JSON has no comments and no trailing commas, and most real parsers accept at least one of them anyway — under a flag, by default, or because the runtime's implementation was always permissive.

That creates a file that works on the machine where it was written and fails on the one where it is deployed, with an error pointing at a line that has been fine for months. Nothing changed except which parser read it.

The tolerant parser is the dangerous one, because it lets a non-conforming file accumulate more non-conformance until something strict finally reads it. If a configuration format needs comments, use one that has them — , JSON5 or TOML — rather than relying on a parser's generosity, which is a dependency you did not declare.