jsonpost
JSON5JSONCConfig

JSON vs JSON5 vs JSONC — What's the Difference?

Comments, trailing commas, and unquoted keys — understand JSON5 and JSONC, where each is used, and how to convert them to strict JSON.

JSONPost··6 min read
JSON vs JSON5 vs JSONC

Strict JSON is intentionally minimal: no comments, no trailing commas, and every key must be wrapped in double quotes. That minimalism is exactly why JSON is such a reliable data-interchange format — every parser on every platform agrees on what's valid. But the same strictness makes JSON awkward for one very common job: configuration files that humans edit by hand. That's where JSON5 and JSONC come in. This guide explains what each one allows, where you'll meet them, and how to convert them back to strict JSON when a tool demands it.

Why strict JSON is so strict

JSON was designed as a wire format, not a config language. When a server sends a payload to a browser, both sides need to parse it identically with zero ambiguity, so the spec forbids anything that could be interpreted differently. The following, for example, is not valid JSON:

{
  // the API base URL
  name: 'jsonpost',
  tags: ['json', 'tools',],
}

It has four separate violations: a comment, an unquoted key (name), single-quoted strings, and a trailing comma after the last array item. Paste that into a strict parser and it throws. For data flowing between machines, that rigidity is a feature. For a config file you tweak every day, it's a papercut.

JSONC: JSON with comments

JSONC is the smaller step. It's plain JSON plus two conveniences: // and /* */ comments, and tolerance for trailing commas. You've almost certainly used it — it's the format behind tsconfig.json and VS Code's settings.json. A typical JSONC file looks like this:

{
  // Compiler options for the project
  "compilerOptions": {
    "target": "ES2022",
    "strict": true,
    "moduleResolution": "bundler" /* recommended for bundlers */
  },
  "include": ["src/**/*"],
}

Notice the line comment, the block comment, and the trailing comma after the include array — all illegal in strict JSON, all fine in JSONC. Everything else is exactly standard JSON: double-quoted keys and strings, no other surprises.

JSON5: a friendlier superset

JSON5 goes much further, borrowing several niceties from ECMAScript to make hand-editing pleasant. On top of comments and trailing commas, it adds:

  • Unquoted object keys when they're valid identifiers
  • Single-quoted strings, so you don't have to escape every double quote
  • Multi-line strings via a trailing backslash
  • Extra number formats — hexadecimal, leading or trailing decimal points, and explicit + signs
  • Infinity, -Infinity, and NaN as number values

Here's a JSON5 document that uses most of these:

{
  // unquoted keys and single quotes
  name: 'jsonpost',
  version: 2,
  limits: {
    max: +1000,
    ratio: .5,        // leading decimal point
    color: 0xff8800,  // hex number
  },
  note: 'a string that \
continues on the next line',
  trailing: ['a', 'b', 'c'],  // trailing comma is fine
}

Every line here would fail a strict JSON parser, yet it reads naturally and is far easier to maintain than its fully-quoted equivalent.

A side-by-side comparison

It helps to see exactly which features each format supports:

FeatureJSONJSONCJSON5
Double-quoted keys
Comments
Trailing commas
Unquoted keys
Single-quoted strings
Hex / extended numbers
Multi-line strings

Think of it as a ladder: JSON is the strict base, JSONC adds comments and trailing commas, and JSON5 layers on the ECMAScript-style conveniences.

Where you'll meet each one

These formats aren't just academic — you use them constantly:

  • JSON — API requests and responses, npm's package.json, JSON Web Tokens, log lines, and anything sent over the network.
  • JSONCtsconfig.json, VS Code settings.json and launch.json, and many editor and tooling configs.
  • JSON5 — Babel configuration, some build tools, and projects that deliberately opt into a more relaxed config syntax.

Knowing which dialect a file uses tells you what your parser needs to handle.

Parsing them in code

Standard JSON.parse only understands strict JSON. For the relaxed dialects you need a tolerant parser. In JavaScript, the json5 package is the usual choice, and it can read all three formats:

import JSON5 from "json5";

// Reads comments, trailing commas, unquoted keys, single quotes…
const config = JSON5.parse(`{
  name: 'jsonpost',
  tags: ['json', 'tools',], // trailing comma
}`);

console.log(config.name); // "jsonpost"

If you only need to strip comments from otherwise-strict JSON, a lighter dependency like strip-json-comments does the job before handing the result to JSON.parse. The key point: never assume a config file is strict JSON — pick a parser that matches the dialect you actually accept.

Converting back to strict JSON

The relaxed formats are great for editing, but the moment you need to send data over the network, store it in a column that expects JSON, or feed it to a tool that only speaks strict JSON, you have to convert. Comments and trailing commas must go; single quotes become double quotes; unquoted keys get quoted.

You can do this in the browser with the JSON5 / JSONC Converter, which strips the extras and emits clean, standards-compliant JSON. For input that's broken in messier ways — mixed quote styles, missing brackets, JavaScript literals like True or None — the JSON Fixer handles a broader set of repairs. And once you have strict JSON, the JSON Formatter will pretty- print it the way you want.

When to use which

A simple rule keeps you out of trouble:

  • Use strict JSON for data on the wire, APIs, databases, and anything another program parses automatically. Compatibility matters more than convenience.
  • Use JSONC when you want comments in an otherwise standard config and your tooling supports it — tsconfig.json is the canonical example.
  • Use JSON5 for hand-maintained configuration where the extra ergonomics (unquoted keys, single quotes, multi-line strings) genuinely make the file easier to live with.

The danger is mixing them up: a JSON5 file handed to a strict parser fails, and a comment that sneaks into an API payload breaks the request. Keep the boundary clear — relaxed formats for humans, strict JSON for machines.

Wrapping up

JSON, JSONC, and JSON5 form a spectrum from strict-and-portable to relaxed-and- ergonomic. Pick the dialect that fits the job, parse it with a matching tool, and convert to strict JSON whenever it has to leave your editor. When that moment comes, run it through the JSON5 / JSONC Converter or the JSON Fixer — both work entirely in your browser.

Keep reading