Format Bench › JSON Validator
JSON Validator
Paste a document and press Validate. If it fails, you get the line, the column, the offending character and a plain-English explanation of the most likely cause.
● Runs locally. What you paste never leaves this page.
What this checks
Validation here means conformance to RFC 8259, the JSON interchange standard, as implemented by your browser's own parser. That is the same parser your application will use if it is written in JavaScript, so a document that validates here will parse in Node and in the browser. Parsers in other languages are overwhelmingly consistent with it for well-formed input.
On success you also get a small structural summary: the root type, maximum nesting depth, total node count, and the size difference between your input and its minified form. Depth is worth watching because some parsers and many schema validators impose nesting limits, and deeply nested documents are usually a sign that an array of objects would model the data better.
Validity is not the same as correctness
A document can be perfectly valid JSON and still be wrong for your purpose. Validation cannot tell you that a required field is missing, that a date is in the wrong format, or that a number should have been a string. That is the job of JSON Schema, which describes the shape a document must take: which properties are required, what types they hold, what ranges are permitted.
The practical division of labour is that syntax validation, which is what this page does, catches typos and truncation, while schema validation catches contract violations. A payload that fails here will fail everywhere. A payload that passes here can still be rejected by the service you send it to.
Common causes, in rough order of frequency
- Trailing comma before a closing bracket or brace.
- Single quotes instead of double quotes, usually from copying a JavaScript or Python literal.
- Unquoted keys, again from a JavaScript object literal.
- Truncation. The document was cut off mid-write, so the parser reports an error at the very end. Log files and copied terminal output are frequent sources.
- Concatenated documents. Two JSON objects written back to back are not valid JSON. If a log emits one object per line, that is NDJSON, and each line has to be parsed separately.
- Python literals.
True,FalseandNoneare capitalised in Python; JSON usestrue,falseandnull. - A byte order mark at the start of the file, which is invisible in most editors and makes the parser fail at position zero.
When the reported position looks fine
The parser reports where it could first prove the document was malformed, not where the author made the mistake. An unclosed brace on line 4 of a 400-line file is reported at line 400. When the flagged position looks innocent, work backwards looking for something opened and never closed. Running the document through the formatter can help, because indentation makes an unclosed structure visually obvious.
Questions
Does this validate against a JSON Schema?
No. This checks syntax against RFC 8259, meaning whether the document is parseable JSON at all. Schema validation, which checks required properties and types, is a separate step performed by a schema validator against a schema you supply.
Why is the error reported at the last line of my file?
Because that is the first point at which the parser can prove something is wrong. It usually means a bracket, brace or quote was opened earlier and never closed. Formatting the document makes the unclosed structure easy to spot.
My log file has one JSON object per line and it fails. Why?
Several JSON documents concatenated together are not one valid JSON document. That format is called NDJSON or JSON Lines, and each line has to be parsed on its own.
Is Python's dict output valid JSON?
Often not. Python's repr uses single quotes and capitalises True, False and None. Use json.dumps to produce valid JSON rather than printing the dictionary directly.