JSON is everywhere, but it's a pain to write by hand. Every key needs double quotes, comments aren't allowed, and one trailing comma breaks everything. JSON5 was created to fix that — it's JSON, but written for humans first. This is the story of why it exists, what it changes, and where it's actually supported today.

The problem: JSON was built for machines

JSON (JavaScript Object Notation) was designed in the early 2000s as a lightweight data interchange format — a way for programs to send data to each other. The priorities were minimal, unambiguous, and easy to parse. Human comfort was not on the list.

That design choice made sense for the original use case. But then something changed: JSON stopped being just a wire format and became a configuration format. People started writing package manifests, build configs, and settings files in JSON — files that humans read, edit, and review by hand every day.

And that's where JSON's strictness turns from a feature into a bug:

You can't leave a comment explaining why a value is what it is.
You can't have a trailing comma, so reordering lines breaks the file.
Every key must be double-quoted, adding noise to every line.
Strings can only use double quotes, so you end up escaping quotes everywhere.

Why JSON5 appeared

JSON5 came out of that frustration. It was proposed around 2012 by Aseem Kishore with contributions from the community, with a simple goal: take JSON and relax it so it's pleasant to write by hand, without turning it into a whole new format.

The design principle is stated right on the JSON5 homepage: JSON5 is a strict superset of JSON and a strict subset of ECMAScript 5.1. The name follows from that — it's the JSON syntax as defined in the ECMAScript 5 language spec, where object literals are far more forgiving than the JSON grammar.

In other words: any valid JSON is valid JSON5, and any valid JSON5 is valid JavaScript. If you've ever pasted a JavaScript object literal and thought "this is basically JSON," you were looking at JSON5.

What JSON5 changes

Here are the concrete differences, all legal in JSON5 but errors in strict JSON.

1. Comments

{
  // line comment
  "name": "John", /* block comment */
  "age": 30
}

2. Unquoted keys

{
  name: "John",
  age: 30
}

3. Single-quoted strings

{
  'name': 'John',
  'path': 'C:\Program Files\app'
}

4. Trailing commas

{
  "name": "John",
  "age": 30,
}

5. Relaxed numbers

{
  "hex": 0xFF,
  "leading": .5,
  "trailing": 5.,
  "positive": +1,
  "infinite": Infinity,
  "notANumber": NaN
}

JSON vs JSON5, side by side

JSON

{
  "name": "John",
  "skills": ["js", "react"]
}

JSON5

{
  name: 'John', // human-friendly
  skills: ['js', 'react',],
}

The key difference is a matter of philosophy: JSON optimizes for machines, JSON5 optimizes for humans — while staying fully convertible to JSON. Strip the comments, add double quotes, and remove trailing commas, and you're back to strict JSON.

JSON5 vs JSONC vs HJSON

JSON5 isn't the only attempt to make JSON friendlier, and the three are often confused:

JSONC — "JSON with Comments". Used by VS Code's settings.json. As the name says, it only adds comments — no unquoted keys or trailing commas. Far more limited than JSON5.
HJSON — "Human JSON". A separate project with a similar goal, but it goes further and diverges from JSON more (omitting quotes and colons entirely in places).
JSON5 — sits in the middle: strictly a superset of JSON, so any JSON parser can understand the output once you normalize it.

Where JSON5 is supported today

JSON5 is a spec and a set of libraries — not a native web standard. The support picture:

Not in the browser or Node by default. JSON.parse is strict JSON only. If you pass JSON5 to it, it throws.
The json5 npm package. The reference JavaScript implementation, used across the ecosystem. It parses and stringifies JSON5 with an API that mirrors JSON.parse/ stringify.
Build tooling. Tools like Babel and Vite read JSON5 (or JSON5-like) config files. TypeScript's tsconfig.json tolerates comments and trailing commas — closer to JSONC than full JSON5, but the spirit is the same.
Other languages. Ports exist for Python, Go, Rust, and more, so JSON5 config files can be read across a stack.

So in practice: JSON5 is widely used in the JavaScript ecosystem, but not a format you can hand to an arbitrary parser and expect to work. That gap is exactly why normalizing JSON5 back to strict JSON matters.

Why JSONGuy cares

That's the whole reason JSONGuy supports JSON5 natively. Paste a JSON5 object — comments, unquoted keys, single quotes, trailing commas — and the formatter normalizes it into strict, standards-compliant JSON that any system can consume. It reads like a human, and writes like a machine.

Try it in the JSON5 formatter, or read a shorter comparison if you just want the differences at a glance.

What is JSON5? Why it exists, what it fixes, and where it's supported