Format Comparison Guide
JSON, JSON5, JSON6, JSOX, YAML and TOML side by side, feature by feature.
TL;DR: JSON6 sits between JSON5 and JSOX. It is JSON5 plus a handful of ECMAScript 6 conveniences, and JSOX is JSON6 plus extra data types. Only JSON has a mature standard and universal parser support; for everything else, check that your reader supports the format before you choose it.
Choosing a data format is mostly about two questions: who writes the file, and who reads it. This page answers both for six formats. The first table covers syntax, the second covers the practical matters of standards, parsers and typical use. Entries marked with a check are supported, a cross means not supported, and text means there is a qualification. Facts about JSON6 were checked against json-6 1.1.7; the other formats are described at the level of their published specifications.
Syntax features
What each format lets you write.
| Feature | JSON | JSON5 | JSON6 | JSOX | YAML | TOML |
|---|---|---|---|---|---|---|
| Comments | // /* */ | // /* */ | # | # | ||
| Trailing commas | Not applicable | Arrays only | ||||
| Unquoted keys | Identifiers only | Broad (hyphens allowed) | Bare keys: letters, digits, _, - | |||
| Single-quoted strings | Literal strings | |||||
| Back-tick strings | ||||||
| Multi-line strings | Backslash continuation only | Raw newlines kept | Block scalars | """ strings | ||
| Hexadecimal numbers | ||||||
| Binary and octal numbers | 0b 0o | Octal only | 0b 0o | |||
| Digit separators | _ | _ | ||||
| Infinity and NaN | .inf .nan | inf nan | ||||
undefined keyword | ||||||
| Empty array members | ||||||
| Native dates | Depends on schema | |||||
| Big integers, typed arrays, Map, cyclic references | Anchors and aliases |
JSON6 and JSOX columns follow the projects' own README files. If a cell matters to you, test it: the online validator runs the real JSON6 grammar in your browser.
Standards, parsers and typical use
The practical side of the choice.
| Format | Standing | Parsers | Best for |
|---|---|---|---|
| JSON | ECMA-404 and IETF RFC 8259 | Built into virtually every language and runtime | APIs, storage, data exchange |
| JSON5 | Published specification at json5.org | Reference JavaScript library plus ports in several languages | Human-edited configuration shared across tools |
| JSON6 | Project README and reference parser; explicitly not an official successor to JSON | json-6 on npm for JavaScript; also in the sack.vfs Node.js native addon | Human-edited files read by Node.js, TypeScript or browser code |
| JSOX | Same author as JSON6; IETF Internet-Draft draft-buckeyne-jsox-format (a draft, not a standard) | JavaScript reference implementation | Object exchange that needs dates, big integers and richer types |
| YAML | Versioned specification (1.2 is current) | Mature libraries in most languages | Deeply nested configuration, CI pipelines, Kubernetes manifests |
| TOML | Versioned specification (1.0) | Libraries in most major languages | Flat to moderately nested application configuration |
Standing matters. A format with a published specification gives parser authors something to test against. For JSON6 the reference parser is effectively the specification. We say that on every relevant page rather than hide it; see Why JSON6.
The same data in each format
A small service configuration shows the difference in feel. All five versions below describe the same data.
JSON
{ "name": "svc", "port": 8080, "mode": 420, "tags": ["a", "b"] }No comments, and the file mode is an unexplained 420.
JSON5
{ name: 'svc', port: 0x1F90, // 8080 mode: 420, // 0644 octal tags: ['a', 'b',], }Comments help, but octal has to be written in decimal.
JSON6
{ name: 'svc', port: 0x1F90, mode: 0o644, // real octal tags: ['a', 'b',], }Octal reads as octal.
YAML
name: svc port: 8080 mode: 0o644 tags: - a - bNo braces, but indentation is meaningful.
TOML
name = "svc" port = 8080 mode = 0o644 tags = ["a", "b"]Compact for flat data; deeper nesting needs table headers.
How to choose
JSON6 or JSON5
If your files will be read by tools written in several languages, choose JSON5: it has a specification and ports. If the files are read only by your JavaScript or TypeScript code and you want 0o and 0b numbers, digit separators or back-tick strings, choose JSON6. JSON6 parses every valid JSON5 document, so the move from JSON5 to JSON6 is a one-way upgrade of what you may write. See the migration guide.
JSON6 or JSOX
JSOX is a superset of JSON6 from the same author. It adds types such as Date, BigInt, typed arrays and references. If you only need what JSON6 offers, the smaller format is easier to explain to your team. If you are serializing in-memory objects with dates and big numbers, JSOX is the better fit.
JSON6 or YAML and TOML
YAML and TOML leave the JSON family. They trade braces for indentation or table headers. If your data is already JSON-shaped, or you want one parser for config and data, a JSON-family format avoids a second syntax. If you value standard parsers in every language more than JSON-like syntax, YAML or TOML is the safer pick.
JSON6 or JSONC
JSONC means JSON with comments, and in practice often trailing commas too, as implemented by editors and TypeScript. It is the smallest step away from JSON. JSON6 goes much further, but JSONC is the one your editor already understands.
FAQ
Is JSON6 faster than JSON5?
The JSON6 README claims nearly double the speed of the JSON5 implementation, with the word "subjective" beside it. Benchmark your own data if it matters.
Can I convert JSON6 to JSON?
Yes. Parse with JSON6.parse() and serialize with JSON.stringify(), or run json-6 -c file.json6 to write a sibling .json file. Comments, holes and undefined do not survive.
Does TOML or YAML replace JSON6?
They solve overlapping problems with a different syntax. If you want the object-literal feel, stay in the JSON family.
Decided on JSON6?
Keep the cheat sheet handy while you write your first file.