JSON Validator
Check whether JSON is valid and get the exact line, column and cause of any syntax error.
JSON Validator tool
Duplicate keys
What this tool does
This validator answers one question — is this document valid JSON? — and when the answer is no, it tells you which character is at fault. You get the line, the column, the line itself reprinted with a caret under the offending character, and a sentence explaining what the parser expected there instead.
When the answer is yes, it reports the document's shape: the type of the root value, how many keys, objects and arrays it holds, how deeply it nests, and its size in bytes. It also flags duplicate keys, which parse without complaint but quietly discard a value.
Common uses
- Proving a config file is the problem — or proving it is not — before you restart a service that refuses to boot.
- Checking a hand-edited fixture or seed file after a merge conflict has been resolved by hand.
- Confirming that a webhook body or log line captured from production is intact and not truncated mid-transfer.
- Spotting a duplicate key in a large object where two branches both added the same field.
- Measuring nesting depth before feeding a document to a parser with a depth limit.
A short example
Given this input:
{
"replicas": 3,
"flags": ['beta', 'canary']
}the report reads:
Single quotes are not valid in JSON — strings and keys
both require double quotes. (line 3, column 13)
"flags": ['beta', 'canary']
^Valid JSON is not the same as correct JSON
RFC 8259 defines syntax, not meaning. A document can pass every check here and still be rejected by the service you are sending it to, because that service also cares about which fields exist and what they contain. Three distinctions are worth keeping straight:
- Duplicate names. Section 4 says object names "SHOULD be unique" and calls the behaviour with duplicates unpredictable. JavaScript and Python both keep the last occurrence; other parsers differ. That is a data-loss bug waiting to happen, which is why it is reported here rather than ignored.
- Top-level scalars. Since RFC 7159 a bare
42,"text"ornullis a complete, valid JSON document. Older tools built against RFC 4627 insist on an object or array at the root. - Schema. Types, required fields and value ranges belong to JSON Schema, a separate specification. This tool does not check them.
Worth knowing
A byte order mark at the start of a file is not part of JSON. RFC 8259 §8.1 says
implementations must not add one and may ignore one on input — but many parsers do not, so a
file that looks identical to a working one can still fail. If a document validates here and
fails in your pipeline, check the first three bytes for EF BB BF and check the
encoding: JSON text exchanged between systems must be UTF-8.
Frequently asked questions
Does JSON allow comments?
No. The grammar in RFC 8259 has no comment production at all, so // and /* */ are syntax errors here and in every conforming parser. Files such as tsconfig.json and VS Code’s settings.json are JSONC, a separate dialect their own editors understand. Strip the comments before validating, or keep the file with a parser that documents JSONC or JSON5 support.
Why are NaN and Infinity rejected?
RFC 8259 §6 allows a number to be only an optional minus sign, digits, a fraction and an exponent — there is no literal for a non-finite value. Python’s json.dumps writes NaN and Infinity anyway unless you pass allow_nan=False, which is why a file produced by Python fails here with an unexpected token. Emit null or a string instead.
My log file has one object per line and it will not validate. Is it broken?
No — that is JSON Lines, sometimes called NDJSON, and only each individual line is a JSON document. The file as a whole never was one. Check a single line here, or fold the lines into an array first with jq -s . file.jsonl. Docker, BigQuery and most structured loggers emit this shape, and jq reads it natively with no flag.