JSON5 vs JSON

JSON's strictness is the feature: RFC 8259 is why every parser on earth agrees. JSON5 trades some of that universality for human comfort — comments, unquoted keys, single quotes, trailing commas, hex numbers. Keep JSON for anything a program reads; allow JSON5 only in config files every consumer parses with the same library.

Local-only

Every JSON file that has annoyed a human does it the same way: you cannot explain why a field exists, you cannot temporarily disable a block, and removing the final comma is busywork the parser could forgive. JSON5 is the community's answer — a strict superset of JSON, modelled on ECMAScript 5 syntax, that adds comments, relaxes quoting and tolerates trailing commas plus a few numeric conveniences. Valid JSON is always valid JSON5; the reverse is never true.

The specification lives at json5.org rather than in any IETF document, and that placement is the honest summary of the trade. RFC 8259's grammar is what guarantees a payload written in Tokyo parses identically in Toronto — one page of rules, no dialects. JSON5 reintroduces the question strict JSON never asks: which parser, and which version of it? Browsers ship JSON.parse and nothing else, so JSON5 always means a dependency.

That is why the split in practice is clean: JSON for the wire and anything stored, JSON5 for human-maintained configuration where a parser dependency is a one-time cost and comments earn their keep. This page walks through what JSON5 adds, what it costs and where the line sits — with the site's local JSON tools ready to check either side.

Curious where your file sits on the strictness line? The JSON Validator parses RFC 8259 locally and flags the first construct a strict parser rejects.

For files already inside the strict subset, the JSON Formatter normalises quoting, keys and indentation in your browser, nothing uploaded.

What JSON5 actually adds

JSON5's extensions all come from ES5 object-literal syntax — the place JSON came from originally. Comments return, as // to end of line and /* block */. Keys may be unquoted when they are valid identifiers. Strings may use single quotes and more escapes. Numbers gain hexadecimal, a leading or trailing decimal point, a leading plus sign, and the special values Infinity, -Infinity and NaN. Trailing commas are allowed in both containers.

Feature	JSON (RFC 8259)	JSON5
Comments	None — removed deliberately	// and /* */ allowed
Object keys	Double-quoted strings only	Unquoted valid identifiers
String quotes	Double quotes only	Single or double
Trailing commas	Syntax error	Allowed
Numbers	Decimal only, no leading +	Hex, +.5, 5., Infinity, NaN
Standard	RFC 8259 / ECMA-404	json5.org spec, library-defined

The cost: who can read the file

JSON.parse rejects the first comment, single quote or bare key it meets — there is no browser-native JSON5 and no server platform that ships one. Every consumer therefore needs the same library, pinned to compatible behaviour. The moment a document stops being strict JSON, “any parser works” stops being true — and that guarantee is the main thing RFC 8259 was buying.

A subtler cost is the dialect zoo growing in the gap: JSONC — comments and trailing commas only — is what tsconfig and VS Code actually accept, and it is not JSON5, since JSONC keeps strict quoting and numbers. Files drift between dialects, editors disagree on highlighting, and a toolchain upgrade can turn a tolerated construct into an error. Strict JSON has no such ambiguity to manage.

Where each one belongs

The split follows the reader. Configuration written and reviewed by humans benefits from comments that explain a field, commented-out toggles during debugging, and unquoted keys that reduce noise — that is JSON5 territory, wherever the toolchain already supports it. Anything a program emits or consumes — API payloads, stored state, structured logs, queue messages — stays strict JSON, where universality is the whole point.

Wire format: JSON, always — any consumer must parse it with zero shared configuration.
Human-maintained config: JSON5 or JSONC, if your tools already speak it natively.
Schema and docs: strict JSON pushes explanation into schemas, because comments have nowhere to live.
Data at rest: JSON — its future readers include tools that have not been chosen yet.

Converting between them

JSON to JSON5 is free: strict JSON already parses as JSON5, so “converting” is a matter of style, not structure. JSON5 to JSON is lossy in exactly the ways you would expect: comments have no destination and disappear, and Infinity, -Infinity and NaN have no JSON value, so they become null or strings. Everything else survives: keys gain quotes, quotes normalise, hex numbers arrive as the same value in decimal.

You can watch the boundary yourself: paste a JSON5 file into a strict validator and the first error points at the construct that crossed it — a comment, a quote, a trailing comma. The diagnostic works in the other direction too: if a config file must someday be read by strict tooling, keep it inside the strict subset from day one, because downgrading is the lossy trip.

When to pick which

Default to JSON and reach for JSON5 only with a reason. The reason is a file humans maintain and machines merely consume — build config, feature flags, environment definitions — combined with a toolchain that already parses JSON5 natively. If your consumers are unknown, external or long-lived, strictness is not bureaucracy; it is the interface contract.

The guidance reverses cleanly: a config file that has never once needed a comment does not need JSON5 either, and a JSON5 file that a service has started parsing at runtime has quietly become a wire format — which means it wants to be JSON again.

Frequently asked questions

Can I format or validate JSON here without uploading the file?

Yes. The formatter and validator run entirely in your browser tab — parsing uses the browser's own JSON engine against RFC 8259, no request leaves the page, the site's Content-Security-Policy blocks outbound calls, and the DevTools Network panel stays silent. Config files never leave your machine. Strict JSON validates; JSON5 extensions appear as syntax errors naming the exact construct.

Is JSON5 an official standard?

Not in the RFC sense. It is specified at json5.org and anchored by its reference implementation and community, whereas JSON has RFC 8259 and ECMA-404. In practice that means no conformance language, no registry, and interop guaranteed only by sharing the same parser — the opposite of JSON's any-parser-will-do promise.

Why doesn't JSON support comments?

Douglas Crockford removed them deliberately when standardising the format: vendors had begun embedding parsing directives inside comments, which broke interoperability between implementations. A data interchange format must mean the same thing to every reader, so the grammar stayed minimal. The surviving conventions are sibling keys like "_comment", or JSONC where the toolchain permits.

Can JSON.parse handle JSON5?

No — it throws at the first comment, single quote, unquoted key or trailing comma, which is most real JSON5 files immediately. You need the JSON5 library or a rewrite to strict JSON first. Watch the JSONC trap too: a parser that accepts comments and trailing commas is still not a JSON5 parser, and it will reject single quotes and hex numbers.

Does converting JSON5 to JSON lose data?

Comments do — they have no legal JSON representation, so any converter discards them by design. Infinity, -Infinity and NaN lose their values, becoming null or strings depending on the converter. Everything else survives: unquoted keys gain quotes, single quotes become double, hex numbers arrive as the same value in decimal. If the comments matter, the file should stay where comments are legal.

Should my config be JSON5 or YAML?

If your toolchain already speaks JSON5, stay — migrating costs more than the comments are worth. Starting fresh, YAML is the more battle-tested human-config format, with block scalars, anchors for reuse and a decade of tooling, at the price of indentation sensitivity and type inference. JSON5's advantage: it stays one small step from strict JSON, so promoting a config to machine data is trivial.

ToolsByUs team · How we check our tools

JSON5 vs JSON explained