JSON validator

What “valid JSON” actually means

JSON is defined by RFC 8259 and by ECMA-404, which describe the same grammar. It is a small grammar — small enough to print in full — and validity is a purely syntactic question. A document is valid if it is exactly one JSON value, optionally surrounded by whitespace, and nothing else.

A JSON value is one of seven things:

Whitespace between tokens may only be space (U+0020), horizontal tab (U+0009), line feed (U+000A) or carriage return (U+000D). A non-breaking space pasted from a word processor is not whitespace to a JSON parser; it is an illegal character, and it is invisible, which is why this validator names it explicitly when it finds one.

Things that are valid and surprise people

• "hello" on its own is a valid JSON document. So is 42, true and null. The old RFC 4627 required the top level to be an object or an array; RFC 7159 removed that restriction in 2014 and RFC 8259 kept the change. Some elderly parsers and some strict API gateways still reject a scalar at the top level.
• {} and [] are valid — empty is fine.
• {"": 1} is valid. The empty string is a legal key.
• {"a": 1, "a": 2} is not forbidden. The spec says names should be unique but does not require it. See below for why that is a security problem.
• 1e400 is syntactically valid even though it is beyond the range of a double. JSON.parse returns Infinity for it; other parsers differ.
• "\uD800" — a lone high surrogate with no partner — is accepted by the grammar and by JSON.parse, even though the resulting string cannot be encoded as valid UTF-8.

Things that are invalid and surprise people

• A trailing comma anywhere: [1, 2,], {"a": 1,}.
• Comments of any kind: //, /* */, #.
• Single-quoted strings, and unquoted object keys.
• NaN, Infinity, -Infinity, undefined.
• Numbers written as .5, 5., +5, 0x1F, 1_000, 007.
• A real newline or tab inside a string. They must be \n and \t.
• A byte order mark before the opening brace. The BOM is invisible, entirely legal in a UTF-8 file, and rejected by every conforming JSON parser.
• Two documents concatenated. One file, one value.

How this validator reports errors

The browser’s own JSON.parse decides validity, so the verdict matches what your code will do. But JSON.parse messages are terse and engine-specific, so when it refuses, a second pass runs: a strict RFC 8259 scanner that walks the text looking for the first illegal construct and tries to name it in the terms a developer would use.

You get four things:

1. A named cause. Not “unexpected token” but “Trailing comma before }”, “Unquoted property name: port”, “Unescaped line feed (a real newline) inside a string”.
2. A position. Line, column and raw character index, so it works whether your editor counts lines or offsets.
3. The line, with a caret. Long lines are windowed around the caret so that a minified single-line document still produces a readable excerpt.
4. What to do about it. A hint aimed at the actual cause — that a Windows path needs its backslashes doubled, that a zip code beginning with zero has to be a string, that a document starting with < is an error page.

The scanner is cross-checked against JSON.parse on twenty thousand randomly mutated documents. The two agree on every one about whether the input is valid, so the diagnosis never contradicts the verdict.

Worked examples

{
  "host": "db.internal"
  "port": 5432
}

{
  "name": "Ada"
}

{"users":[{"id":1,"name":"Ada"},{"id":2,"na

What a syntax validator cannot tell you

Valid JSON is a very low bar. It says nothing about whether the document means what you intended:

• Schema conformance. Whether age is a number, whether email is present, whether status is one of three allowed strings. That is JSON Schema, enforced by a library such as Ajv (JavaScript), jsonschema (Python) or everit (Java).
• Semantic sanity. {"temperature_celsius": 4000} is perfectly valid JSON.
• Encoding correctness. A document can be valid JSON and still be mis-decoded on arrival if the producer wrote UTF-8 and the consumer assumed Latin-1. The symptom is é where é belongs — valid JSON containing wrong text.
• Duplicate-key safety. Since duplicates are not forbidden and parsers resolve them differently — JavaScript keeps the last, some keep the first, some error — a crafted payload can be validated by one service and acted on differently by another. If you consume untrusted JSON, reject duplicate keys explicitly rather than relying on the parser.
• Size safety. A deeply nested document can exhaust a recursive parser’s stack; a large one can exhaust memory. Both are valid JSON. Bound the depth and the byte length before parsing untrusted input.

Validating JSON without a browser

For files, a scriptable check is usually better than a web page. All of these run locally and exit non-zero on failure, so they drop straight into a pre-commit hook or a CI job:

# jq — prints the parsed document, or an error with a byte offset
jq empty file.json

# Python, in the standard library, no dependencies
python3 -m json.tool file.json > /dev/null

# Node.js
node -e 'JSON.parse(require("fs").readFileSync(process.argv[1],"utf8"))' file.json

# Every .json file in a repository, stopping at the first failure
find . -name '*.json' -not -path './node_modules/*' -print0 \
  | xargs -0 -n1 -I{} sh -c 'jq empty "{}" || echo "FAILED: {}"'

A web page is the better tool when you have a snippet rather than a file, when you want to see where the error is rather than read an offset, or when you want to explore the shape of an unfamiliar payload afterwards. That is why this page hands you the tree view and the statistics the moment the document validates.

Frequently asked questions

Related pages

• JSON formatterPretty-print, tree view and statistics
• “Unexpected token” explainedEvery cause of the most common JSON error
• “Unexpected token < … position 0”Your API returned HTML, not JSON
• “Unexpected end of JSON input”Empty bodies, truncation and double-reads
• “JSON.parse: unexpected character”The Firefox and Safari wording, decoded
• JSON minifierStrip whitespace and measure the saving
• Escape & unescape stringsJSON string literals, both directions

Related tools

• Regex testerTest and debug regular expressions against sample text