About JSON Validator
This checks whether a document is well-formed JSON and, when it is, reports what kind of value it contains — an object with a given number of keys, or an array with a given number of items. When it is not, the parser's own error message is returned, which usually names the position of the problem.
Knowing the shape of the top-level value is more useful than it sounds. A great many integration failures come down to an endpoint returning an object where the caller expected an array, or a single object where it expected a list of them; the key or item count makes that visible immediately rather than after a debugging session.
The error message is the part worth reading carefully. JSON parsers report where parsing stopped rather than where the mistake was made, so the real fault is often a few characters before the reported offset — a missing comma on the previous line being the single most common cause.
How to use JSON Validator
- 1 Paste the document to check.
- 2 A valid document reports its type along with the number of keys or items.
- 3 An invalid document reports the parser error, which points at where parsing stopped.
Frequently asked questions
The error points at a position where nothing looks wrong. Why?
Because parsers report where they stopped, not where the mistake is. A missing comma between two entries, for example, is only detected when the parser reaches the following token. Look a few characters before the reported position — the previous line is usually the culprit.
It says valid, but my application rejects it. What else could be wrong?
Syntax and schema are different things. This checks that the document parses as JSON; it does not check that the fields your application requires are present, or that their types are what it expects. A syntactically perfect document can still fail validation against a schema.
What counts as the top-level type?
The kind of value the document starts with — an object, an array, a string, a number, a boolean, or null. Objects and arrays are the two you will meet in practice, and the count reported tells you how many keys or items are directly inside.
Can JSON have comments?
No. Standard JSON does not permit comments of any kind, and a document containing // or /* */ will be rejected as invalid. Some configuration formats add comment support as an extension, but a strict parser will not accept them.
Free, online, and private
Free to use
JSON Validator is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How JSON Validator behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Parsing | a single JSON.parse call — the strict grammar, with no tolerance for comments or trailing commas |
| Error reporting | the first error only, in the wording of the engine that produced it |
| Success output | the type (array, or the typeof result) plus the item count for arrays, or the top-level key count otherwise |
| Empty input | invalid — an empty or whitespace-only document reports an unexpected end of JSON input |
Compiled from the implementation of this tool and checked against it by itoolnet.
What JSON Validator does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- Only the first problem is ever shown, because one JSON.parse call throws at the first offending token. A file with five separate mistakes reports one of them and says nothing at all about the remaining four.
- The message is the browser's own wording, passed through unchanged, so it varies between engines and this tool adds no line or column reference, no surrounding context and no suggested fix of its own.
- The literal null is reported as invalid even though it is valid JSON. The success branch asks for the parsed value's keys and that call throws on null, so the TypeError is caught and printed as an invalid-JSON message.
- It checks syntax only. There is no schema validation, no type checking and no duplicate-key detection — {"a":1,"a":2} is reported valid and counted as a single key, because the parser keeps the last value.
Tested and documented by itoolnet, the team that builds and maintains this site.