JSON Validator: check JSON syntax online and find the error
JSON
Result
Paste a document to check it.
What does a JSON validator do?
It reads your document the way a parser would and tells you whether it is well-formed, before whatever you were going to send it to rejects it. Paste a document and it either confirms the JSON is valid or points at the exact line and column where it stops making sense, with the offending line and a caret under the character.
That is quicker than the usual loop of sending a payload, waiting for a 400, and decoding an error written for the server rather than for you. And when the document is valid, the panel says what it turned out to be: an object or an array, how many keys, how deeply nested, how large. That is often the actual question, because a config that parses can still be the wrong shape.
Why use it?
- Find the typo faster. A missing comma fourteen levels into a minified payload is hard to see and trivial to point at. The caret marks the character the parser choked on, and the message says what it expected instead.
- Check before you send. Useful when the request is expensive, rate-limited, or going somewhere that will log a malformed body as an incident.
- Catch a duplicate key. Nothing else in a normal workflow will mention one, and it is the one kind of valid JSON that means different things to different readers.
Example
The document below has a trailing comma after "emails" and another after the last value. Both are ordinary in JavaScript and neither is legal JSON:
{
"service": "ingest-worker",
"retries": 3,
"queues": ["leads", "emails",],
}{
"service": "ingest-worker",
"retries": 3,
"queues": ["leads", "emails"]
}Duplicate keys are valid, and worth knowing about
This document is valid JSON, and every checker will tell you so:
{
"timeout": 30,
"retries": 3,
"timeout": 90
}RFC 8259 says the names in an object should be unique and stops short of requiring it, so what happens next is up to the reader. JavaScript keeps the last value, 90. Python's json module also keeps the last. Some parsers keep the first, some collect both, and a few refuse the document outright. If the thing that wrote your file disagrees with the thing that reads it, the value silently changes.
So the verdict here stays “valid”, because anything else would be wrong, and every repeat is listed underneath with its path and line, each one a link that jumps the cursor to it. The JSON Formatter can merge them for you with Merge Duplicate Keys.
What “valid” does not mean
It means the document is well-formed JSON. It does not mean it is the JSON something else is expecting. The checker has never seen the API you are calling or the schema it validates against, so it cannot know that a required field is missing, that "30" should have been a number rather than a string, or that a date is in the wrong format. A document can be perfectly valid JSON and still be rejected by the first system that reads it.
Common reasons a document is rejected
- A trailing comma before a closing
}or]: legal in JavaScript, never in JSON. - Single quotes. JSON has one kind of string and it is double-quoted, keys included.
- An unquoted key.
{name: "x"}is a JavaScript object literal, not JSON. - Comments. JSON has none. Config files collect them anyway, which is what the Allow Comments switch is for.
NaN,undefined, or01. None are JSON values. Numbers cannot have leading zeros, and there is no way to write infinity.- Several documents in one file. One value per document. A stack of objects, one per line, is NDJSON and has to be checked a line at a time.
How to use the tool
- Paste your JSON into the panel on the left, or open a file.
- The verdict appears on the right as you type. If it fails, press the heading to jump the cursor to the character that caused it.
- If your file is a config with comments or trailing commas, turn the matching switch on in the toolbar and check it again.
Options
| Option | What it controls | Possible values |
|---|---|---|
| Allow Comments | Whether // and /* */ are accepted. Off means strict JSON, which has no comments | On, Off (default) |
| Allow Trailing Commas | Whether a comma before a closing bracket is accepted. Off means strict JSON, which does not allow one | On, Off (default) |
Both are off by default on purpose. Strict RFC 8259 is the thing worth checking against: a file that only passes because the checker was told to be lenient has not been validated, it has been excused, and the parser at the other end may not be as forgiving.
Frequently asked questions
Is my JSON sent to a server?
No. The check runs entirely in your browser: the document is never uploaded, stored or logged, and the page keeps working if you go offline after it loads. That matters here more than for most formats, since the thing people most often need to check is an API payload, and those tend to carry personal data or an access token.
Does a valid result mean my API will accept it?
It means the document is well-formed JSON. It does not mean it is the JSON something else is expecting: the checker has never seen your API or its schema, so it cannot know that a required field is missing, that a number was sent as a string, or that a date is in the wrong format. A document can be perfectly valid JSON and still be rejected by the first system that reads it.
What is the difference between this and the JSON Formatter?
They share a parser, so anything that formats is valid and anything that fails does so for the same reason in both. The formatter exists to produce output, beautified or minified, and reports an error only as the thing stopping it. The validator exists to report: it gives you the failing line in context with a caret under the character, and when the document holds up it tells you what it turned out to be (object or array, how many keys, how deep, how large) and lists any duplicate keys.
Why does it only report one error at a time?
The parser stops at the first thing it cannot read, because everything after that point depends on how the first problem is resolved. A missing bracket, for instance, makes every following line ambiguous. Fix the one it names and re-check; the next one, if there is one, appears immediately.
It says duplicate key, but the document is valid. Which is it?
Both. RFC 8259 says the names in an object should be unique but stops short of requiring it, so a repeat is legal and every parser resolves it differently: JavaScript and Python keep the last, some keep the first, a few reject the document. That makes it a warning rather than an error: the file is valid, and what it means depends on who reads it. Each repeat is listed with its path and line, and the JSON Formatter can merge them.
My config file has comments. Is it still JSON?
Strictly, no. JSON has no comments, which is why they are rejected by default. Plenty of tools accept them anyway under the name JSONC, so there is a switch in the toolbar for both comments and trailing commas. Turn it on and the same file passes; leave it off and you are checking against the standard, which is what a parser at the other end is likely to be doing.
Can it check JSON against a schema?
Not yet. Schema validation answers a different and often more useful question, whether the document has the fields something expects and with the right types, and it needs a schema to check against. This tool checks the syntax only.
Is there a size limit?
Not on what you paste, but a file you open has to be under 1 MB. Past that the editor itself becomes slow, which is a worse experience than being told no. The parsing runs in a background thread, so a large document does not freeze the page while it works.