JSON VIEW PARSER

What a Validator Checks

JSON is defined by RFC 8259, and its grammar is unusually strict for a format this widespread. There are no optional conveniences: no trailing commas, no single quotes, no unquoted keys, no comments. A validator's job is to confirm your text obeys those rules, and to tell you precisely where it stops doing so.

That strictness is deliberate. Because the grammar admits so little variation, every conforming parser in every language agrees on what a document means — which is the property that made JSON usable as a universal interchange format in the first place. The cost is that a single stray character invalidates the whole file.

The Rules, In Full

JSON's complete syntax fits in one list. If your document satisfies all of these, it is valid:

• Exactly one top-level value. Usually an object or array, though any value is legal. Two values side by side is not a JSON document — that is JSON Lines, a different format.
• Double quotes only. Every key and every string value must use ". Single quotes are a syntax error, not a stylistic choice.
• Every key must be a quoted string. {name: "Alice"} is valid JavaScript and invalid JSON.
• No trailing commas. The last element of an object or array must not be followed by a comma, however much your editor wants to add one.
• Matched, correctly nested brackets. Every { needs a } and every [ needs a ], closed in the order they were opened.
• Only seven value types. String, number, object, array, true, false, null. There is no date type, no undefined, no NaN, no Infinity.
• Numbers follow a restricted format. No leading zeros (01 is invalid), no leading +, no hexadecimal, no trailing decimal point (1. is invalid), and a decimal point must be followed by at least one digit.
• No comments. Neither // nor /* */ is permitted anywhere.
• Control characters must be escaped inside strings — literal newlines and tabs are not allowed. See the escaping guide.

Why the Error Line Is Often Wrong

This trips up almost everyone, and understanding it will save you more time than any other single fact about validation.

A parser reads left to right and reports a problem at the first point where the input becomes grammatically impossible. That is frequently not where you made the mistake. Consider a missing comma:

{
  "name": "Jane Doe"
  "age": 25
}

The mistake is on line 2 — a comma should follow "Jane Doe". But after reading that string the parser is perfectly happy; a value can legally be followed by a comma or by a closing brace. It only discovers something is wrong on line 3, when a string turns up where one of those two things was required. So the error says line 3, pointing at a line that is entirely correct.

The practical rule: when a JSON error names a line, check the line above it first. The same logic explains trailing-comma errors, which are reported on the closing brace rather than on the comma itself.

Worked Examples

Each of these fails validation. The cause is rarely where you would guess.

Trailing comma

{
  "name": "Jane Doe",
  "hobbies": ["reading", "cycling"],
}

Reported at line 4, on the }. After a comma the parser requires another key; it found a closing brace instead. Remove the comma on line 3.

Single quotes

{
  'name': 'Jane Doe'
}

Reported at line 2, column 3. A key must begin with "; the parser will not accept ' under any circumstances. This usually means the text came from a Python repr() or a JavaScript object literal rather than from a real JSON serialiser.

Unescaped inner quotes

{
  "quote": "She said "hello" to me"
}

The string ends at the quote before hello, so the parser sees a bare word where a comma should be. Escape the inner quotes as \\", or use single quotes inside the string — those are fine as content, just not as delimiters.

Not JSON at all

<!DOCTYPE html>
<html><head><title>502 Bad Gateway</title></head>

Reported at position 0 with an unexpected <. Your API returned an HTML error page. Nothing is wrong with your JSON handling — check the HTTP status code and Content-Type header instead. This is the most common "invalid JSON" report in web development.

Syntax Validation Is Not Schema Validation

A validator confirms your document is well-formed. It cannot tell you whether the document is right. These two are entirely different guarantees, and conflating them causes a lot of misplaced confidence.

This document is flawlessly valid JSON and would break most applications immediately:

{
  "user_id": "not-a-number",
  "email": null,
  "created_at": "yesterday",
  "permissions": "admin"
}

Every bracket matches and every string is quoted, so a syntax validator passes it without comment. Catching these problems requires declaring what the data should look like — see the JSON Schema guide.

Validating From the Command Line

For scripting and CI pipelines, you want a validator that sets an exit code rather than one that draws a page:

# jq: exits 0 if valid, non-zero with a message if not
jq empty data.json

# Python, no extra dependency required
python3 -m json.tool data.json > /dev/null

# Validate every JSON file in a repository
find . -name '*.json' -not -path './node_modules/*' \
  -exec sh -c 'jq empty "$1" || echo "INVALID: $1"' _ {} \;

Adding jq empty as a pre-commit hook is a cheap way to stop a malformed config file from ever reaching your main branch.

Validating on This Site

Paste your document into the input panel. Validation runs as you type — a valid document renders in the output panel, and an invalid one produces the parser's message along with the line and column where the grammar first failed.

Everything happens in your browser. Nothing is uploaded, so validating a real API response with customer records in it carries no disclosure risk. You can confirm this by disconnecting from the network: the page keeps working.

Frequently Asked Questions