JSON5 vs JSONC vs JSON: Comments and Trailing Commas

Why JSON is so strict

JSON (RFC 8259) was designed as a data interchange format, where predictability beats convenience. No comments means no place for a parser to disagree; no trailing commas means no ambiguity; double quotes everywhere means one rule. That strictness is exactly why JSON is universally parseable — but it also makes hand-edited config files fragile, since one stray comma breaks the whole file and you cannot leave a note explaining a setting.

What JSONC adds

JSONC means JSON with Comments. Popularized by Visual Studio Code (its settings and tsconfig files are JSONC), it adds two things to standard JSON: single-line and block comments, and trailing commas. That is the whole feature set — it stays very close to JSON, which makes it easy to support and easy to strip back to strict JSON. JSONC is the pragmatic choice when all you really want is to annotate your config and stop fighting commas.

{
  // the port the server listens on
  "port": 8080,
  "hosts": ["a", "b",]  // trailing comma is allowed
}

What JSON5 adds

{
  name: 'Ada',   // unquoted key, single-quoted string
  hex: 0xFF,      // hexadecimal number
  list: [1, 2,],  // trailing comma
}

• Comments — both single-line and block, like JSONC
• Trailing commas in objects and arrays
• Unquoted object keys that are valid identifiers
• Single-quoted strings and multi-line strings
• Extra number formats: hexadecimal, leading or trailing decimal points, and positive/negative Infinity and NaN

JSON5 versus JSONC: which to use

Think of it as a spectrum of looseness. JSONC is a minimal, conservative extension — comments and trailing commas, nothing else — and is the right pick when you want JSON that is barely relaxed and widely understood by editor tooling. JSON5 is a fuller human-friendly dialect with unquoted keys and single quotes, better when you are authoring config by hand and want it to feel like writing a JavaScript object.

If a tool you use already speaks one of them (VS Code uses JSONC), follow that convention. For your own files, choose JSONC for maximum compatibility or JSON5 for maximum ergonomics.

They are for authoring, not interchange

Both JSONC and JSON5 are meant for files humans write, not for data sent between systems. Most runtimes, APIs, and data stores accept only strict JSON, so a JSON5 or JSONC file usually needs to be converted before it travels. Keep the relaxed file as your editable source of truth and produce strict JSON as the output.

Converting back to strict JSON

Converting strips comments, removes trailing commas, quotes keys, and normalizes single quotes to double quotes, producing output that passes a standard parser. Note that comments are lost in the process — they are not representable in strict JSON — so keep the original if you need them. The JSON5 Validator checks JSON5 syntax and converts it to clean JSON, and a standard JSON Validator is the right tool when a file must be strict JSON with no authoring conveniences allowed.