What it does
Format turns minified or messy JSON into clean indented output you can actually read.
Validate happens automatically. If the JSON is broken you get the parser’s own error message, including where it gave up.
Minify strips every byte of whitespace for production.
Compare takes two documents in JSON A and JSON B and returns a structural diff: added, removed, changed and type-changed entries, each with its full path. Key order never counts as a difference, and arrays compare by position.
JSON to CSV flattens an array of objects, taking headers from the union of all keys and leaving missing values blank. CSV back to JSON uses the first row as headers.
Nested objects get rejected with a clear error rather than quietly mangled.
Large numbers get silently corrupted
This is the JSON bug that costs the most time, because nothing ever errors.
The data just comes out wrong.
JavaScript stores every number as a 64-bit float. That represents integers exactly only up to 9,007,199,254,740,991, which is 2 to the power of 53 minus 1, exposed as Number.MAX_SAFE_INTEGER.
Go past it and precision falls off the end.
Parse {"id": 9007199254740993} in a browser and you get back 9007199254740992. No warning. No exception. Just a different number than the one that was sent.
Database bigint primary keys land in this range routinely. So do snowflake IDs, the 64-bit identifiers used by X, Discord and others.
A corrupted ID points at the wrong record, or at nothing at all, and the failure surfaces somewhere far away from the parsing that caused it. You end up debugging the wrong file.
The fix lives on the sending side: send large integers as strings. {"id": "9007199254740993"} survives any parser intact, because a string is copied rather than converted. Consuming an API that insists on sending them as raw numbers? You need a parser with BigInt support rather than the default one, and you need to reach for it before the value has been through JSON.parse even once, since by then the damage is already done and there is nothing left to recover. This is also why so many APIs return IDs as strings when the underlying column is plainly an integer. It looks like sloppy typing and it is usually deliberate.
Why JSON has no comments
People discover this the hard way, usually inside a config file.
Comments were left out deliberately.
Douglas Crockford, who wrote the spec, took them out on purpose. He had watched people hide parsing instructions inside comments, which meant two tools could read the same file and disagree. Removing comments kept JSON as plain data with nothing to interpret.
For config files this is annoying, which is why other formats exist. JSONC adds comments and is what VS Code uses for its own settings. JSON5 goes further, allowing comments, trailing commas, unquoted keys and single quotes.
Neither one is JSON. A strict parser rejects both.
If a file needs comments, pick one of those on purpose rather than hoping whatever reads it turns out to be lenient.
The old trick also still works: add a "_comment" key. Ugly, and completely valid.
The three syntax errors people hit
Trailing commas. {"a": 1, "b": 2,} is invalid. JavaScript allows that final comma, the habit carries over, and JSON refuses it.
Single quotes. {'a': 1} is invalid. JSON wants double quotes on keys and on string values, with no exceptions anywhere.
Unquoted keys. {a: 1} fails for the same reason. Perfectly good JavaScript, not JSON.
All three come from writing JSON as though it were JavaScript. It looks like a subset of the language and behaves like a much stricter one, which is exactly the sort of near-miss that costs an afternoon. If you are hand-editing a config file and something will not parse, check those three before you check anything else, because between them they account for most broken JSON in the wild.
Duplicate keys are undefined
{"a": 1, "a": 2} parses without complaint in most implementations and hands you 2, because the last value wins.
The spec does not require that. It calls the behaviour undefined, so another parser could give you 1, or throw an error, or keep both. Some strict checkers reject the whole document.
You rarely write duplicates by hand. They turn up when JSON gets built by gluing strings together, or merged from two sources without anyone checking for clashes.
If your output goes somewhere you do not control, check for them rather than trusting every parser downstream to resolve it your way.
Frequently asked questions
Will it tell me what is wrong?
Yes. Invalid JSON shows the parser’s own error message, which usually points straight at the character where parsing gave up.
Can I compare two JSON documents?
Switch to Compare and paste both. You get every added, removed and changed entry listed by path, with key order ignored and arrays compared by position.
Can I convert JSON to CSV and back?
Yes, in JSON to CSV mode. Going to CSV needs a flat array of objects. Coming back the other way, your first row becomes the headers.
Why can I not put comments in my JSON?
They were left out of the format on purpose. Use JSONC or JSON5 if you need them, and expect strict parsers to reject both.
Why did my large ID number change?
It went past 9,007,199,254,740,991, which is the largest integer a JavaScript number holds exactly. Send big IDs as strings.
Is a trailing comma allowed?
No.
Related: JSON to CSV converter · JSON to YAML · Base64 encode and decode · decode a JWT