JSON Linter

Structural and style checks — duplicate keys, mixed naming conventions, inconsistent array shapes, null-heavy fields. Not a syntax check.

Paste JSON to lint it

Valid JSON isn't the same as well-structured JSON. This tool checks for the structural and style problems a syntax validator can't see — duplicate keys, inconsistent naming, arrays whose items don't all have the same shape — the kind of issues that quietly break a downstream parser or confuse the next person who has to read the data.

  • Duplicate keys — flags what JSON.parse silently threw away
  • Mixed naming conventions across sibling keys
  • Arrays of objects with inconsistent item shapes
  • The same field typed differently across array items
  • Fields that are null often enough to question the schema
  • Excessive nesting depth

Linting vs. Validating — Different Questions

JSON Validator answers "is this syntactically valid JSON?" — brackets balanced, strings quoted, no trailing commas. This tool assumes the answer is already yes and asks a different question: "is this JSON well-structured?" A document can be perfectly valid and still have a duplicate key silently overwriting data, or an array where item #47 is missing a field every other item has.

JSON ValidatorJSON Linter
ChecksSyntax onlyStructure and consistency
CatchesMissing commas, unquoted keys, broken bracketsDuplicate keys, mixed naming, inconsistent shapes
A valid JSON file can still fail thisN/AYes — validity and structure are independent
Best usedBefore parsing, to confirm the JSON is usable at allAfter validating, to review data quality

Why Duplicate Keys Are Worth Catching

{"role":"editor","role":"admin"} is valid JSON — JSON.parse accepts it without complaint and silently keeps only the last occurrence (role: "admin" here), discarding the first. If that document was hand-edited, merged from two sources, or generated by buggy code, the duplicate is a real bug that produces no error anywhere — it just quietly loses data. This linter scans the raw text (not the parsed result, since the duplicate is already gone by then) specifically to catch this.

Why Inconsistent Array Shapes Matter

An API response, a database export, or a JSON Lines log file is often an array of records that's supposed to be uniform — every order has the same fields, every user has the same fields. When it isn't — one record is missing a field, or has an extra one nobody else has — code that assumes uniformity (a CSV export, a typed deserializer, a table renderer) breaks or silently produces a blank column on exactly the rows that differ. This check flags which array indices deviate from the majority shape, so you can find the odd ones out without eyeballing every record.

Frequently Asked Questions

No — run Validator first if you're not sure the JSON is syntactically valid; this linter requires valid JSON as input and checks structure/style issues on top of that, not instead of it.

The check requires at least 2 keys matching each competing style before flagging — a single snake_case key next to otherwise-camelCase keys (e.g. one intentional id field) is common enough not to be worth a warning on its own.

A field that's null in 50% or more of the items in an array of at least 4 records. Below 4 records there isn't enough of a sample to say whether null-heavy is meaningful or just how a small dataset happens to look.

No — it reports findings only. For duplicate keys or inconsistent shapes, the fix depends on which value or shape is actually correct, which only you know; blindly auto-fixing could silently pick the wrong one.

No — linting runs entirely in your browser using JavaScript. Nothing is uploaded.

Related Tools