JSON Validator

Two different questions

People ask “is my JSON valid?” about two unrelated things, and a document can pass one while failing the other badly.

A response of {"error":"rate limited"} is perfectly valid JSON and completely useless to code expecting a user record. Syntax validity is the floor, not the goal.

Reading the error

Native parser messages describe where the parser gave up, which is usually one token *after* the mistake, and report a byte offset rather than a place a person can navigate to. A missing comma on line 12 is commonly reported at the start of line 13.

Jsonviewpro re-scans failing input to report the location and the cause separately:

Invalid JSON        Line 3, Column 28

Trailing comma before the closing bracket.
Remove the comma after the last array item.

   3 │   "roles": ["admin", "user",]
     │                           ^

Go to line jumps the cursor there. Try repair appears only when the fix is unambiguous, and tells you exactly what it changed — your input is never altered without you asking.

Every reason a document fails to parse

This is the complete set, with the message Jsonviewpro gives for each. In practice the first five account for almost everything.

Valid, and still wrong

These parse cleanly, so no validator will complain, and each has caused real production incidents:

• Duplicate keys. {"a":1,"a":2} is permitted by the specification, which declines to say what a parser should do about it. JavaScript and Python keep the last occurrence; some parsers keep the first; a few throw. Never emit them.
• Integers beyond 2^53 − 1. 9007199254740993 parses to 9007199254740992 in any JavaScript engine. Nothing warns you. Send large identifiers as strings.
• An empty body. Zero bytes is not valid JSON, but a literal null, {} or [] is — and each means something different from the others.
• HTML pretending to be JSON. A login redirect or a proxy error page will fail to parse with a confusing message. Check the status code and Content-Type before you blame the JSON.

Checking the shape with a JSON Schema

Open Validate against a JSON Schema above and paste a schema next to your document. Each violation is reported with the path that failed.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":     { "type": "integer", "minimum": 1 },
    "email":  { "type": "string", "format": "email" },
    "status": { "enum": ["active", "invited", "disabled"] }
  }
}

$          Instance does not have required property "email".
$.id       Instance type "string" is invalid. Expected "integer".

Drafts 04, 07, 2019-09 and 2020-12 are all supported, chosen automatically from the schema’s own $schema. Validation runs in your browser, and $refs to remote schemas are never fetched.

Validate at the boundary, not in the middle

The lesson from most JSON-related incidents is not “validate more”, it is “validate early”. Check the payload the moment it arrives — at the API handler, the queue consumer, the file loader — and reject it there with a message naming the field.

A malformed document that travels three services deep produces a stack trace in the wrong place, and the engineer reading it has no idea which upstream sent it.

Validating in a script or CI

# Is it valid? Exit status only.
jq empty input.json && echo valid

# Python, with the position of the failure
python3 -c "import json,sys; json.load(open(sys.argv[1]))" input.json

# Every JSON file in a repository, as a pre-commit check
find . -name '*.json' -not -path './node_modules/*' -exec jq empty {} ;

# Against a schema, in CI
npx ajv-cli validate -s schema.json -d data.json