JSON Validator

JSON is stricter than you think

JSON looks like JavaScript, but the grammar is far less forgiving. Strings and object keys must use double quotes — single quotes are illegal. Comments are not allowed in any form. Trailing commas after the last array element or object property are a syntax error. Numbers may not have leading zeros, and NaN, Infinity and undefined simply do not exist in JSON.

These rules trip people up daily because so many tools produce almost-JSON: a config file edited by hand, an API payload assembled with string concatenation, a log line copied with the end truncated. The text looks right until a strict parser rejects it — usually at the worst possible moment, like during a deployment.

It does not help that different environments report these failures differently. One runtime says “Unexpected token } in JSON at position 148”, another says “property name must be a string”, and minified input turns every position into a meaningless offset into a single giant line. This validator normalizes all of that into one consistent format — what went wrong, the exact line, the exact column — regardless of which browser you open it in.

Where validation failures come from in the real world

The most common sources we see: a package.json or tsconfig edited with a trailing comma left after deleting the last entry; a payload built by concatenating strings where a value containing a quote breaks out of its string; a response copied from a browser console that silently truncated a 2MB body; and “smart quotes” introduced by pasting through Word, Slack or a rich-text editor, which replace straight double quotes with curly ones that JSON does not recognize.

Validating before you ship — paste the payload here before wiring it into curl, a test fixture or a config deploy — turns a confusing runtime crash into a ten-second fix.

How to read a JSON error message

A parser reports the first position where the text becomes impossible to continue — which is not always where your mistake actually is. If you see “Expected ',' or '}' at line 8, column 17”, the parser got to that character legally and then failed; the real typo is often just before it, such as a missing quote closing the previous string.

That is why this validator shows more than a message: the error line is highlighted in the editor, “Jump to error” places your cursor on the exact character, and “Show error context” reveals the surrounding lines with a caret (▲) pointing at the offending position. Read backwards from the caret and the fix is usually obvious.

Valid syntax is not the same as valid data

A green “Valid JSON” result means one thing precisely: your text conforms to the RFC 8259 grammar. Every bracket is balanced, every string is double-quoted, every number is well-formed. It does not mean the data matches what your API expects — a payload can be perfectly valid JSON and still miss a required field, use a string where a number belongs, or nest an object one level too deep.

That second layer of checking is called schema validation, and it happens after syntax validation, not instead of it. The practical workflow is: paste here first to catch syntax errors instantly, then let your application’s schema (JSON Schema, Zod, io-ts) enforce structure. Catching the syntax layer here is still worth it — a trailing comma produces a wall-of-text parser exception in most languages, while this tool reduces it to one highlighted line and a ten-second fix.

When the document validates, the status card also reports key count, maximum nesting depth, byte size and line count — a quick fingerprint you can compare between two versions of a payload to confirm you are looking at the same shape of data.