A duplicate key
Valid JSON that silently keeps only the last value, which no parser warns about
{"a": 1, "a": 2}JSON Validator & Formatter
Paste JSON and get a straight answer on whether it is valid, with the exact line and column of any error and what most likely caused it. Then the formatted version, and a warning about the one thing that goes wrong silently.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Validate & format. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A trailing comma
The error located to a line and column rather than reported generally
{"a": 1,}Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Assuming a duplicate key is an error
It is valid JSON. Parsers keep the last value silently, so a config with a key written twice uses the second and the first looks authoritative.
Instead:Check for duplicates explicitly. No parser will tell you.
Writing a trailing comma
JSON does not allow it, unlike JavaScript. It is the most common hand-editing error and the message is usually about an unexpected token.
Instead:Use JSON5 or YAML if you want trailing commas, and keep strict JSON for interchange.
Relying on key order
Objects are unordered by specification. Most parsers preserve insertion order in practice, but nothing guarantees it across languages.
Instead:Use an array if order is meaningful.
What it checks
Validity first. Then the two problems that are valid JSON and still wrong.
Errors named for what they are
A parser written for this rather than a wrapper around JSON.parse, whose messages vary by browser and no longer include a position in Node 22. Trailing commas, single quotes, unquoted keys, comments, missing commas, bad escapes and Python's None each get named, with a caret under the character.
Numbers that lose precision
JSON numbers are IEEE 754 doubles, so an integer above 9,007,199,254,740,991 changes value when parsed. Snowflake ids, database bigints and amounts in minor units are the usual casualties, and no parser in any language reports it. This does.
Duplicate keys
The spec does not say what should happen, so parsers disagree. Most keep the last occurrence and silently discard the first, which means the value you get depends on the library.
Format and minify
Two-space indentation with keys left in their original order, plus the minified size so you can see what whitespace is costing. Comments cannot be preserved, because a document with comments would not have parsed.
What JSON actually allows, and what it does not
JSON's grammar fits on a postcard, which is its great strength and the source of nearly every error people hit. Most invalid JSON is invalid because the author wrote something JavaScript would accept, and JSON, despite the name, is not a subset of anything you can just write from memory.
The four things that are not allowed
No trailing comma after the last element. No comments of any kind. Keys must be double-quoted strings, not bare words and not single-quoted. Strings must use double quotes. Every one of these is legal JavaScript and none of them is legal JSON, which is why a config file copied out of a code editor so often fails to parse.
{
"name": "api", // comments are not allowed
'port': 8080, // single quotes are not allowed
region: "eu-west", // unquoted keys are not allowed
"tags": ["a", "b",], // trailing comma is not allowed
} // and this one tooNumbers have no integer type
JSON has one number type and the specification puts no limit on its size, but almost every parser reads numbers into a 64-bit float. That gives exact integers only up to 2 to the power of 53. A larger value: a Twitter-style snowflake id, a Postgres bigint, a nanosecond timestamp: is silently rounded, and the failure appears much later as an id that does not match anything.
{"id": 9007199254740993}
parses to 9007199254740992 the last digit is gone
send large ids as strings: {"id": "9007199254740993"}Duplicate keys are undefined behaviour
The specification says object keys should be unique but does not say what to do when they are not. Parsers differ: most keep the last value, some keep the first, a few error. A config file with a repeated key is therefore valid JSON whose meaning depends on which library reads it: the kind of difference that shows up as an environment behaving differently for no visible reason.
The relaxed variants, and where each is accepted
JSON5 and JSONC add the comments and trailing commas people keep reaching for, and NDJSON puts one document per line for streaming. They are genuinely useful and they are not JSON: an API expecting JSON will reject them. Worth knowing which one a given file is, since a .json extension says nothing about it: tsconfig.json and VS Code's settings are JSONC and would fail a strict parse.
JSON strict, what an API expects
JSONC JSON + comments tsconfig.json, .vscode/settings.json
JSON5 + trailing commas, unquoted keys, single quotes
NDJSON one JSON value per line, for logs and streams