JSON Validator

A rejected config file, a webhook the receiver silently drops, a deploy that fails with nothing but SyntaxError: Unexpected token } in the logs — the fix is usually one character, and the entire task is finding it. This validator parses your document with the browser's native JSON.parse and reports the first fault with its line and column, so you can go straight there instead of bisecting the file by hand.

When the document does parse, you get more than a green tick: a summary of what the parser actually saw — the root type, how many objects, arrays and scalar values it contains, and the maximum nesting depth. That is a fast way to confirm a payload holds the twelve records you expected rather than one record and an empty array, without reading a single line of it.

What RFC 8259 actually permits

JSON is a small specification, and most validation failures come from assuming it is slightly larger than it is. The complete grammar allows six value types — object, array, string, number, true/false, and null — and nothing else. In particular:

• Strings must use double quotes. Single quotes are a syntax error, in keys and values alike.
• Object keys must be quoted strings. Bare identifiers such as {name: "x"} are JavaScript, not JSON.
• There are no comments. Neither // nor /* */ is legal anywhere in a JSON document.
• A trailing comma after the last element of an object or array is invalid.
• NaN, Infinity, -Infinity and hexadecimal or leading-zero numbers are all outside the number grammar. Only true, false and null are permitted as bare literals, and they are lower case.
• A leading byte order mark is not part of the document and will cause the parse to fail on the very first character.

Two things that surprise people by being legal: duplicate keys, and a bare scalar as the whole document. {"id":1,"id":2} parses fine and the last value wins silently, which makes duplicate keys a genuinely dangerous bug rather than a loud one. And 42, "hello" or null on their own are each a complete, valid JSON document under RFC 8259 — the older RFC 4627 required an object or array at the top level, which is why some legacy parsers still reject them.

Syntax validation is not schema validation

This tool answers one question: does the text parse as JSON? It deliberately does not claim to answer the other one: does this document contain the right fields, of the right types, within the right ranges? That question can only be answered against a JSON Schema, and asserting validity without one would be dishonest.

The practical consequence is that a document can pass here and still be rejected by the API you send it to, because quantity arrived as the string "3" instead of the number 3, or a required currency field is missing entirely. Syntax is the floor. The structure summary this tool prints — root type, counts, depth — is often enough to catch that class of mistake by eye, but it is not a substitute for a schema check in your pipeline.

The awkward cases

Truncated files. If a download or a log capture was cut short, the error will point at the very end of the document and complain about an unexpected end of input. That is the parser telling you the file is incomplete, not that the last line is wrong.

Smart quotes. JSON pasted out of a word processor, a ticketing system or a chat client frequently has " and " in place of ". They look almost identical in a proportional font and are a hard syntax error. If the reported column looks like it is pointing at a perfectly ordinary quote mark, this is usually why.

Invisible characters. A non-breaking space or a zero-width space copied along with the text is not valid JSON whitespace and will fail at a position that appears blank.