100% local — your data never leaves your browser

JSON Validator — The Line and Column to Fix

Check that JSON parses, with the line and column when it does not. You go straight to the character that broke it instead of hunting for it.

Instant Private Zero cookies

JSON input

Result output

What the report says

For a document that parses: the shape of the root value and the size.

✓ Valid JSON

Root: object (4 keys)
Size: 312 characters, 18 lines

For one that does not: the parser’s message, with the position translated into a line and a column — once, not twice.

Any JSON value is a document

42 is valid JSON. So is "hello", so is true, so is null.

That has been true since RFC 7159 (2014); the original RFC 4627 required an object or an array at the top level. Some older parsers still enforce the old rule, which is worth remembering the day a validator says yes and your library says no.

Duplicate keys: a warning, not an error

{ "port": 8080, "port": 3000 }

The report says the document is valid, and adds a note with the position of the second port.

That is a deliberate difference from the JSON formatter, which refuses the same input. RFC 8259 says names in an object should be unique — a SHOULD, not a MUST — so the document really is valid, and a validator describes what it sees.

A formatter has to produce something, and producing means deciding which of the two values survives. Different parsers decide differently: most keep the last, some keep the first, some reject. That choice belongs to you, not to a tool, so the formatter stops and the validator warns.

What valid does not mean

It does not mean the file says what you think.

A missing required field, a string where a number belongs, a date written the American way, a URL with a typo — all of that parses perfectly. Checking it needs a schema — JSON Schema, and a validator that reads it — which is a different question from the one this page answers.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why is a duplicate key a warning here and an error in the formatter?
Because the two tools have different jobs. RFC 8259 says names *should* be unique — a SHOULD — so a document that repeats one is still valid JSON, and a validator’s job is to describe what it sees. A formatter has to produce one output, which means choosing which value survives, and that choice is not the tool’s to make.
Is 42 valid JSON?
Yes. Since RFC 7159 any JSON value is a complete document: a number, a string, `true`, `null`. The older RFC 4627 required an object or an array at the top, which is why some old parsers still refuse `42` — worth knowing when a validator and your library disagree.
It says valid, but my program rejects the file. Why?
Because valid means the syntax parses, not that the content is what something expects. A missing required field, a number where a string was declared, a date in the wrong format — none of that is syntax. Checking it needs a schema, which is a different tool and a different question.

Related converters