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.