All three formats describe the same data model — objects, arrays, strings, numbers, booleans, null — but they disagree on how forgiving the syntax is. Here’s the full picture.

The same document, three dialects

Strict JSON (RFC 8259 / ECMA-404):

{
  "server": "api.example.com",
  "port": 8443,
  "options": ["tls", "http2"],
  "ratio": 0.5,
  "max": null
}

JSONC — JSON with Comments (VS Code’s dialect):

{
  // internal endpoint — not the public one
  "server": "api.example.com",
  "port": 8443,        // dev uses 8080
  "options": ["tls", "http2"],   // trailing comma is usually tolerated
  "ratio": 0.5,
  "max": null,
}

JSON5 — the full superset:

{
  // comments, single quotes, unquoted keys
  server: 'api.example.com',
  port: 0x2104,            // hex: 8452
  options: ['tls', 'http2',],   // trailing comma fine
  ratio: .5,               // leading dot ok — so is 5.
  max: Infinity,           // Infinity/NaN exist
  multiline: 'first \
second',                   // backslash continues the line
}

Feature-by-feature

Feature	JSON	JSONC	JSON5
// and /* */ comments	✗	✓	✓
Trailing commas	✗	✓*	✓
Single-quoted strings	✗	✗	✓
Unquoted object keys	✗	✗	✓
Hex / leading . / trailing . numbers	✗	✗	✓
+5, Infinity, NaN	✗	✗	✓
Multi-line strings (\ continuation)	✗	✗	✓
Every spec-compliant parser reads it	✓	✗	✗

*JSONC is a convention, not a spec — “comments” is the only guaranteed extension; most implementations also allow trailing commas. Microsoft’s own parsers do.

Who speaks what

• Strict JSON: every JSON.parse, every REST/GraphQL API, jq, Python’s json, Go’s encoding/json, package manifests like package.json, lockfiles, OpenAPI definitions. Default assumption for anything crossing a network or a checksum.
• JSONC: VS Code settings/keybindings, tsconfig.json / jsconfig.json, devcontainer.json, .babelrc, Azure Resource Manager templates, .swcrc. If a file lives in an editor’s config folder, assume JSONC is tolerated.
• JSON5: projects that opt in explicitly — the json5 package on npm, some build-tool configs, a few embedded config systems. Always signals itself via a .json5 extension.

The failure mode that matters

The dangerous direction is strict parser, loose file: a tsconfig.json copied into a CI step that runs JSON.parse explodes on the first //. The reverse — a loose parser reading strict JSON — always works, because JSON5 and JSONC are supersets by design.

Practical rule of thumb:

1. Hand-edited config a human maintains? JSONC/JSON5 if the toolchain accepts it — comments prevent real mistakes (“is this key still needed?” is answered in place).
2. Machine-exchanged data? Strict JSON, always. It’s the only dialect guaranteed to parse identically in every language, and canonicalization for signatures/hashes only works on the strict grammar.
3. Not sure which you have? Paste it into the formatter. A JSON5/JSONC file will fail validation at the first comment or unquoted key — the error message names exactly which extension bit you used.

Frequently asked questions

Is JSON5 just "JSON with comments"?

That's JSONC. JSON5 goes much further: single-quoted strings, unquoted keys, trailing commas, hexadecimal numbers, leading/trailing decimal points, Infinity/NaN, and multi-line strings with a backslash-continuation. JSONC only adds comments and (in most implementations) trailing commas to stock JSON.

Can JSON.parse read a JSON5 file?

No — JSON.parse is strict to RFC 8259. A JSON5 file with comments or unquoted keys throws immediately. You need a JSON5 parser (the json5 npm package) to read it, and likewise a JSONC-aware parser for commented configs. That's why the extension matters: .json should mean strict JSON.

Which tools accept JSONC?

VS Code's own settings files (settings.json), tsconfig.json in TypeScript, devcontainer.json, and Azure templates — all technically JSONC. Many parsers accept comments quietly; others reject the same file. The safest assumption: configs read by Microsoft/JS tooling tolerate comments, anything consumed over an API won't.

Should I write new config files in JSON5?

If your tooling supports it, JSON5 is friendlier to hand-edit — comments and trailing commas remove the two most common syntax errors. For anything exchanged between systems, stored, or signed, stay with strict JSON: every parser on earth agrees on it, and canonical forms (sorted keys, no whitespace) matter for checksums and signatures.