JSON's strict syntax — no comments, no trailing commas — is a deliberate design choice that helps data exchange but hurts hand-edited configuration files. JSONC and JSON5 are two extensions that relax these rules. Here's the difference, where each is used, and how to convert.

JSONC: JSON with comments

JSONC adds two things to JSON:

That's it. No other syntactic changes. Trailing commas are not part of the original JSONC definition, although VS Code's parser tolerates them too.

JSONC is widely used in tooling configuration files:

// tsconfig.json
{
  "compilerOptions": {
    "target": "es2022",     // Modern output
    "strict": true,         // Enable all strict checks
    /* Module resolution */
    "moduleResolution": "bundler"
  }
}

Visual Studio Code introduced JSONC for its own configuration files (settings.json, keybindings.json) and the format spread from there to TypeScript's tsconfig.json, ESLint's config, and many other developer tools. The defining feature is that the parser strips comments before parsing the rest as standard JSON.

JSON5: a bigger superset

JSON5 takes the relaxation further. The full list of differences from JSON:

JSON5 is essentially "what JSON would look like if it had been designed for humans first":

{
  name: 'Alice',     // unquoted key, single quotes
  age: 30,
  scores: [
    95,
    87,
    92,                // trailing comma
  ],
  ratio: .5,         // leading decimal
  hex: 0xFF,         // hex number
}

JSON5 is used by npm (the package.json5 proposal didn't catch on, but JSON5 is supported in some Node.js tooling) and by Babel and some build tools for configuration. It's never used for data exchange between systems.

Which to use

For configuration files that humans edit, JSONC is the safer default — it adds comments without changing JSON's data model, so any JSONC file with the comments stripped is valid JSON. Tooling support is good (VS Code recognizes it natively if you set the file mode to "JSON with Comments").

For configuration files where you want the full flexibility of object-literal syntax, JSON5 works but you'll need a dedicated parser. Most languages have a JSON5 library, but it's an extra dependency.

For data exchange between systems — APIs, message queues, file formats — use strict JSON. Don't even consider JSONC or JSON5 for wire format. The whole point of JSON's strictness is that any conforming parser can read any conforming document; relaxing the syntax breaks that.

Converting JSONC to JSON

The easiest way is to strip comments with a regex (carefully, to avoid matching // inside strings) or use a library:

# Python — using json5
import json5
with open('config.jsonc') as f:
    data = json5.load(f)  # parses JSONC/JSON5
import json
print(json.dumps(data))   # outputs strict JSON

// Node.js — using the jsonc-parser package
import { parse } from 'jsonc-parser';
const data = parse(content);
const strict = JSON.stringify(data);

For one-off conversion, paste your JSONC into our JSON formatter — it's relaxed enough to handle comments and trailing commas, and it outputs strict JSON. (Note: some validators will reject JSONC input; the formatter is the right tool.)

The trade-off

Strict JSON's advantage is universal compatibility. Every language, every parser, every text editor with JSON support understands it identically. JSONC and JSON5 are improvements for hand-editing, but they fragment the ecosystem — your file is no longer just "JSON", it's "JSON in a specific dialect supported by specific tools".

For most projects, the right division is: data wire format → strict JSON, configuration files → JSONC, scripting / generated config → strict JSON. If you're publishing a configuration spec for others to consume, pick one dialect and document it clearly.

What about JSON6?

JSON6 exists but never gained traction. JSONC and JSON5 are the two practical choices for relaxed JSON syntax. If you find yourself reaching for even more flexibility — variables, includes, conditionals — what you actually want is a configuration language like TOML, YAML, or a small DSL. For more on that comparison, see our JSON vs YAML guide.