What does the validator check?

It checks the syntax of one JSON value: matching containers, colons, double-quoted keys and strings, valid escapes including four hexadecimal digits after a Unicode escape, escaped control characters, JSON number syntax, lowercase true/false/null and no trailing commas or comments. It warns about repeated decoded key names, including a and \u0061, while preserving both original tokens. It does not check a JSON Schema, an API contract, JSON-LD semantics or a JSONL stream.

Why does the error give a line and column instead of a character offset?

Because a character offset is unusable in a 4,000 line file. The validator tokenises the document itself and carries the line and column of each token, so the message points at the character your editor can jump to. It also names the cause: 'Trailing comma before ]' rather than 'unexpected token'.

Does it explain mistakes that come from another language?

Yes, by name. True, False and None are recognised as Python and the message says so. undefined, NaN and Infinity are named as JavaScript that JSON does not have. Single quotes are called out as JavaScript string syntax. Comments are identified as JSONC, the extension editors like VS Code use in config files, with the position of the first one so you know what to strip.

Does validating change my document?

No. The verdict is read from your own tokens, and the indented version underneath it is printed from those same tokens rather than from a parsed copy. That is why key order survives, including integer-like keys, and why a 20 digit ID keeps all 20 digits instead of being rounded to about 16 the way parse-and-print tools round it.

Can I get the formatted output too?

Yes. Formatted output appears below the verdict. Choose Formatted to lead with that output or Minified for a compact version, then use the corresponding Copy button. Indentation can be two or four spaces and object keys can be sorted A to Z. Validation never repairs an invalid document.

Is my JSON uploaded for checking?

No. Tokenising, validating and formatting all run in your browser. That matters more for JSON than for most formats, because payloads routinely contain API responses, tokens and customer records that should not be pasted into someone else's server.

JSON Validator

Paste JSON and find out whether it parses, with the verdict first rather than buried under the output. The page opens on a document with one deliberate mistake in it, so you can see what a failure looks like before you paste your own: a trailing comma at line 3, column 29, named as a trailing comma rather than reported as an offset. Fix it or paste over it, and the verdict turns into the key count, the nesting depth and the size.

JSON91 characters

Verdict

Not valid JSON. Line 3, column 29: Trailing comma before ]: JSON does not allow it.

Show

Indent

Keys

Common questions

What does the validator check?: It checks the syntax of one JSON value: matching containers, colons, double-quoted keys and strings, valid escapes including four hexadecimal digits after a Unicode escape, escaped control characters, JSON number syntax, lowercase true/false/null and no trailing commas or comments. It warns about repeated decoded key names, including a and \u0061, while preserving both original tokens. It does not check a JSON Schema, an API contract, JSON-LD semantics or a JSONL stream.
Why does the error give a line and column instead of a character offset?: Because a character offset is unusable in a 4,000 line file. The validator tokenises the document itself and carries the line and column of each token, so the message points at the character your editor can jump to. It also names the cause: 'Trailing comma before ]' rather than 'unexpected token'.
Does it explain mistakes that come from another language?: Yes, by name. True, False and None are recognised as Python and the message says so. undefined, NaN and Infinity are named as JavaScript that JSON does not have. Single quotes are called out as JavaScript string syntax. Comments are identified as JSONC, the extension editors like VS Code use in config files, with the position of the first one so you know what to strip.
Does validating change my document?: No. The verdict is read from your own tokens, and the indented version underneath it is printed from those same tokens rather than from a parsed copy. That is why key order survives, including integer-like keys, and why a 20 digit ID keeps all 20 digits instead of being rounded to about 16 the way parse-and-print tools round it.
Can I get the formatted output too?: Yes. Formatted output appears below the verdict. Choose Formatted to lead with that output or Minified for a compact version, then use the corresponding Copy button. Indentation can be two or four spaces and object keys can be sorted A to Z. Validation never repairs an invalid document.
Is my JSON uploaded for checking?: No. Tokenising, validating and formatting all run in your browser. That matters more for JSON than for most formats, because payloads routinely contain API responses, tokens and customer records that should not be pasted into someone else's server.

Formatting and minification preserve original string and number tokens. Object keys stay as written unless sorting is enabled; sorted keys are compared by decoded name, without case, while array order stays unchanged. Syntax checking is separate from schema validation.