JSONC and JSON5 versus strict JSON
Plain JSON is deliberately minimal: no comments, no trailing commas, double-quotes only. That strictness is intentional for machine-to-machine data exchange, but it makes hand-edited configuration files unnecessarily painful. Two supersets relax those rules for humans.
JSONC (JSON with Comments) adds only two things: C-style line comments (//)
and block comments (/* ... */), plus trailing commas in objects and arrays. It is the
format VS Code uses for settings.json, tsconfig.json, and launch.json.
JSON5 goes much further, drawing on JavaScript object-literal syntax. In addition
to everything JSONC allows, JSON5 also permits unquoted keys, single-quoted strings,
multi-line strings, hexadecimal numbers, numeric values like Infinity and NaN, and
more. It targets configuration files that humans will read and edit extensively.
Feature comparison
Both supersets are parsed by dedicated libraries, never by JSON.parse.
A quick cheat sheet:
| Feature | JSON | JSONC | JSON5 |
|---|---|---|---|
Line comments (//) | No | Yes | Yes |
Block comments (/* */) | No | Yes | Yes |
| Trailing comma in objects | No | Yes | Yes |
| Trailing comma in arrays | No | Yes | Yes |
| Unquoted keys | No | No | Yes |
| Single-quoted strings | No | No | Yes |
| Hexadecimal numbers | No | No | Yes |
Infinity, NaN | No | No | Yes |
Leading decimal point (.5) | No | No | Yes |
Code example
{
// JSONC and JSON5: comments explain the value
timeout: 30, // JSON5 only: unquoted key
host: 'localhost', // JSON5 only: single quotes
hex: 0xFF, // JSON5 only: hexadecimal integer
ports: [3000, 3001,], // trailing comma — valid in both supersets
/* The block below can be toggled off */
debug: false,
}
Strip this through a JSONC parser and only the comments and trailing commas are accepted; an unquoted key would fail. Run it through a JSON5 parser and every line is valid.
Choosing the right dialect
Stay on strict JSON for any API response, wire protocol, or data file that a machine produces and another machine reads. The standard is unambiguous and every language has a battle-tested parser.
Use JSONC when the file is checked into source control and developers benefit from explanatory comments — toolchain configs, VS Code workspace settings, database seed files, or feature flag definitions. The change-set is minimal and the format is accepted by most modern tooling.
Use JSON5 when you want the full authoring convenience of JavaScript object
literals, human readers outnumber machines, and you are comfortable adding the
json5 npm package (or equivalent) to your build.
Parsing in code
// Strict JSON — built-in
JSON.parse('{"key":"value"}');
// JSONC — npm i jsonc-parser
import { parse } from "jsonc-parser";
parse('{ "key": "value", // comment\n}');
// JSON5 — npm i json5
import JSON5 from "json5";
JSON5.parse("{ key: 'value', hex: 0xFF, }");
The single most common mistake: editing a .json file to add a comment or
a trailing comma and then wondering why JSON.parse throws a SyntaxError. Switch
to the JSONC parser if your tooling accepts it, or pre-process with jsonc-parser
to strip extensions back to canonical JSON.