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.
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, andNaNas 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:
| Feature | JSON | JSONC | JSON5 |
|---|---|---|---|
| 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. - JSONC —
tsconfig.json, VS Codesettings.jsonandlaunch.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.jsonis 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
Validating JSON with JSON Schema
Learn how JSON Schema works, how to generate a schema from sample data, and how to validate documents with clear, path-based error messages.
How to Format JSON (and Why It Matters)
A practical guide to beautifying, indenting, and minifying JSON — and when to use each, with tips for debugging messy API responses.
Safely Parsing Untrusted JSON in JavaScript
Parse untrusted JSON in JavaScript without crashing or opening security holes — try/catch, revivers, prototype pollution, schema validation, size and depth limits.