JSON Validator

What “valid JSON” means

JSON is defined by a short specification, RFC 8259, and a document either follows its grammar or does not. There are no warnings in the grammar and no partially valid documents: a parser reads from the first character, and at the first thing it does not expect, it stops and rejects the whole text. That is why one stray comma on line 300 makes an API answer 400 Bad Request for an otherwise perfect body.

This validator applies the grammar strictly, as an API server would. Formats that look like JSON and relax its rules — JSON5, JSONC with comments, a JavaScript object literal — are reported as invalid here, because a server will reject them too.

The errors it explains

For an unclosed object or array, the reported position is where the bracket was opened, not the end of the file, since that is the place you need to look.

Valid, but worth a look

Some documents pass every parser and still do not mean what their author intended. The validator reads the original text rather than the parsed result, so it can see these where JSON.parse cannot.

Duplicate names

{"role": "user", "role": "admin"} is accepted everywhere. The specification says names should be unique and stops short of requiring it, and it notes that implementations differ on which value they keep. Most keep the last. When a gateway that keeps the first value sits in front of a service that keeps the last, the two disagree about what was sent, and that gap has been used to bypass validation. A duplicate is nearly always an editing accident, and it is reported with its position.

Integers beyond 2⁵³ − 1

The grammar puts no limit on the size of a number, but JavaScript and many other parsers store every number as a 64-bit float. Above 9,007,199,254,740,991 not every integer can be represented, so 12345678901234567890 is read as 12345678901234567000 with no error. Database keys and snowflake-style IDs are the usual victims. The fix belongs to whoever produces the JSON: send such values as strings.

A byte-order mark

A file saved as “UTF-8 with BOM” begins with an invisible character. The specification says producers must not add one, and allows parsers to ignore it; some do, and some reject the document at position one with an error that looks baffling because nothing visible is there.

Invisible characters between values

JSON allows four whitespace characters: space, tab, line feed and carriage return. A non-breaking space copied from a web page, a chat message or a word processor looks identical and is not one of them, so this one is a real syntax error. It is reported by its code point, because pointing at an apparently empty spot would not help.

Syntax is not the same as correctness

Passing here means the text is JSON. It does not mean the JSON is what a particular API wants. A body can be perfectly formed and still be missing a required field, hold a string where a number is expected, or use a value outside the allowed set. Those are schema problems, checked by the API itself and usually answered with 422 Unprocessable Content and a list of the failing fields, where a syntax error gets a 400.

Two other causes of a rejected body have nothing to do with the JSON at all. A missing Content-Type: application/json header makes many servers parse the body as form data and fail. And a shell that mangles quotes can corrupt a body between your editor and the wire; the curl POST JSON example shows quoting that survives. When the syntax is fine and the request still fails, send it from the API tester and read the error body the server returns.

Once a document is valid, the JSON formatter will indent or minify it, and the JSON viewer will show it as a tree.

Frequently asked questions

Related tools and reference