JSON Validator
Find out exactly which line and column broke your JSON.
Runs entirely in your browser
Loading the tool…
Most JSON errors are one of four things: a trailing comma, a missing quote around a key, a single quote where a double quote belongs, or an unescaped character inside a string. This validator points at the exact line and column so you stop hunting.
Strict RFC 8259 rules apply, the same ones your parser will use. If it validates here, it will parse in your language of choice.
The message says what is wrong, and the line and column say where, which together are usually enough to fix it without reading the whole document. The line is highlighted in the box so you are looking at the character that stopped the parse rather than counting rows.
Some causes are invisible until you know to look for them. A byte order mark from a Windows editor sits before the opening brace and is not whitespace. Smart quotes from a word processor look almost exactly like the straight ones JSON requires. A tab inside a string has to be written as an escape rather than typed. Copying out of a terminal often brings a stray shell prompt with it.
Valid is not the same as correct. This tells you the document parses, not that it has the fields your program wants, and a service can still reject a perfectly valid document for its own reasons. Once it parses, JSON Formatter makes it readable.
How to use it
- Paste the JSON you want to check.
- Read the verdict. Valid documents report their type and size.
- If it is invalid, jump to the reported line and column and fix the first error.
Questions
Are comments allowed in JSON?
Not in standard JSON. // and /* */ are valid in JSON5 and in config formats like tsconfig.json, but a strict parser rejects them, and so does this validator.
Are trailing commas allowed?
No. [1, 2, 3,] and {"a": 1,} are both invalid JSON, even though JavaScript accepts them. This is the single most common error people paste in.
My JSON is valid but my program still fails. Why?
Syntax and shape are different problems. A document can be perfectly valid JSON while missing the fields your code expects. For that you need schema validation, not a syntax check.
What counts as valid here?
RFC 8259, which is what a strict parser in any language accepts. No comments, no trailing commas, keys in double quotes, no single quotes anywhere, and no NaN or Infinity, which are JavaScript values rather than JSON ones.
Are duplicate keys an error?
Not according to the standard, which leaves the behaviour undefined, and that is the problem: most parsers keep the last one, some keep the first, and a few return both. The document parses here, but a document that relies on it is a bug waiting for a different library.
Why does my number lose precision when it is valid?
Because JSON has one number type and most parsers read it as a 64-bit float, which holds about 15 significant digits. An identifier longer than that, such as a Twitter or Discord snowflake, is safer as a string. The document is still valid; the reader is what changed it.
Is my data uploaded to check it?
No. The parsing runs as WebAssembly in this page, on your own machine. That matters here more than on most tools, because the JSON people need to validate is often a live API response with a token or a customer record in it.
Your data stays on your device
Everything above runs inside your browser as WebAssembly compiled from Rust. Nothing you type is uploaded, logged or stored on a server. You can load this page once, go offline, and it still works.
This page makes no requests at all, to anywhere. That is not a promise in the copy: it is a Content-Security-Policy header your browser enforces, and connect-src on it is none. Open the network tab and watch nothing happen.