JSON Validator and Linter

Valid JSON follows a short grammar defined in RFC 8259. A document holds exactly one value, and every value is one of seven things: an object, an array, a string, a number, true, false or null. The rules that trip people up:

• Strings and object keys use double quotes. Single quotes and bare keys are JavaScript, not JSON.
• Commas go between items, never after the last one.
• There are no comments of any kind.
• Numbers are plain decimals: no leading zeros (07), no leading +, no bare .5, no hex, and no NaN or Infinity.
• true, false and null are lowercase.
• Tabs and line breaks inside strings must be escaped, and the only escapes allowed are \" \\ \/ \b \f \n \r \t and \uXXXX.
• Whitespace between tokens is limited to spaces, tabs, line feeds and carriage returns.

A lone string or number is valid JSON too. The original RFC 4627 required an object or array at the top level; RFC 7159 dropped that rule in 2014 and RFC 8259 kept it that way.

Use Strict for anything a program will read: API requests and responses, message queues, data files and package.json. It is at least as strict as JSON.parse, Python's json module and Go's encoding/json, so if a document passes here it parses there.

Use Lenient for JSONC, the configuration dialect that adds // and /* */ comments and, in most tools, trailing commas. Lenient mode accepts those two extensions and nothing else, so single quotes and unquoted keys are still reported.

Repair converts near-JSON into strict JSON and tells you what it changed, so you can review the result before you rely on it.

Syntax is only the first check. The issues below slip past many parsers and editors, yet regularly cause production bugs, so the validator flags them as warnings:

• Duplicate keys. RFC 8259 says names should be unique but doesn't forbid duplicates, and parsers disagree on what to do. JSON.parse keeps the last value, other parsers keep the first or reject the document. Whichever one your code sees, the other is silently lost.
• Integers beyond 2^53. JavaScript reads 9007199254740993 as 9007199254740992. If an ID can grow that large, send it as a string.
• Numbers too large for a double, such as 1e400, which JSON.parse turns into Infinity.
• A byte-order mark at the start of the file. RFC 8259 forbids adding one and lets parsers ignore it, but JSON.parse throws on it, so a file that opens fine in an editor fails in JavaScript.

I-JSON (RFC 7493), a stricter profile of JSON for internet protocols, turns the first two warnings into rules: object names must be unique, and numbers should fit an IEEE 754 double.

Every language reports syntax errors; most give you a position you can turn into a line and column:

// JavaScript: a SyntaxError whose message includes a position
try { JSON.parse(text); } catch (err) { console.error(err.message); }

# Python: JSONDecodeError has .lineno and .colno
try:
    json.loads(text)
except json.JSONDecodeError as err:
    print(err.lineno, err.colno, err.msg)

# jq: exit status 0 means valid
jq empty data.json

// Go: a quick yes or no, or *json.SyntaxError with an Offset
ok := json.Valid(data)

All of these stop at the first error. This page keeps going and lists every error in one pass, which saves the fix, rerun, fix loop on a large file. Paste the error report into a ticket with Copy error report. Once the JSON is valid, the JSON Formatter pretty-prints, minifies or sorts it.

No. Syntax validation answers "is this JSON?". Schema validation answers "is this the JSON I expect?": the right keys, types, formats and ranges. {"age": "forty"} is perfectly valid JSON that your code may not survive.

For schema validation, describe the expected shape with JSON Schema, which validators such as Ajv check in JavaScript, or with Zod in TypeScript. The JSON to Zod generator writes a Zod schema from a sample document, so you can validate API responses at runtime with one line of code.