Lint JSON — find the mistakes parsers won't accept
JSON FYI's linter goes beyond a yes/no parse. It surfaces trailing commas, duplicate keys, JavaScript-style comments, and Python-style literals — with the exact line and column.
Ready when you are.
Paste JSON on the left, or click Sample to try a quick example. Validation runs as you type — entirely in your browser.
Lint rules
- no-trailing-comma — trailing commas in arrays or objects are invalid JSON.
- duplicate-key — repeated keys in the same object indicate a bug.
- no-comments — JSON has no comment syntax. Move metadata into a sibling field.
- quoted-keys — keys must be double-quoted strings; unquoted identifiers are rejected.
- strict-literals — only
true,false, andnullare valid;True,False,Noneare not.
Examples
[ 1, 2, 3, ]
Lint · line 5, col 1 no-trailing-comma — remove the comma after 3
{
"id": 1,
"id": 2
}Lint · line 3, col 3 duplicate-key — "id" already defined on line 2
{ "ok": True, "data": None }Lint · line 1, col 9 strict-literals — use 'true' instead of 'True' Lint · line 1, col 23 strict-literals — use 'null' instead of 'None'
Use cases
- Cleaning copy-pasted JS
JS object literals look like JSON until you paste them in. The linter highlights every difference.
- Migrating Python dicts
True/False/None and single quotes become true/false/null and double quotes — the linter walks you through each.
- Reviewing pull requests
Run config diffs through the linter to catch trailing commas before merge.
- Teaching JSON
Show, don't tell: the linter explains each rule violation in context.
From the JSON FYI guides
In-depth explanations for common JSON errors and patterns.
What parsers do with them and how to find and remove duplicates.
Why every parser rejects them and how to clean them up.
Why they don't exist in JSON and five workarounds ranked.
The mistakes that cause 90% of parse failures, with fixes.
Frequently asked questions
What's the difference between validating and linting JSON?+
Validation checks whether the document conforms to the JSON spec (it parses or it doesn't). Linting flags patterns that are technically invalid but commonly written by mistake — comments, trailing commas, duplicate keys, unquoted keys.
Why are JavaScript-style comments flagged?+
JSON has no comment syntax. // and /* */ are valid in JavaScript object literals but will break any compliant JSON parser. JSON FYI warns so you can extract them before parsing.
Are duplicate keys an error?+
RFC 8259 says behaviour is undefined — most parsers keep the last value, but it varies. Duplicate keys almost always indicate a bug, so JSON FYI flags them.
Why is True/False/None invalid?+
JSON booleans are lowercase: true and false. There is no None — use null. JSON FYI suggests the correct token when it sees Python-style literals.