Skip to content
Tools

JSON Validator

Validate JSON instantly and identify syntax errors with detailed explanations, line numbers and column numbers. Everything runs locally in your browser.

Visible pane

Input

0 chars

Loading editor…

Waiting for input

Your JSON never leaves your browser. Everything is validated locally.

What is a JSON validator?

A JSON validator answers one question: is this text legal JSON? If it is, the document can be parsed by any conforming library in any language. If it is not, a good validator tells you exactly where it breaks and why.

That second half is what separates a useful validator from a useless one. “Invalid JSON” on its own tells you nothing you did not already know. What you actually need is the position, the reason, and the change to make:

Invalid — a trailing comma on line 3
{  "id": 1,  "name": "Ada",}

The comma on line 3 promises another property that never arrives. Delete it and the document parses. That is the whole job: what went wrong, where, why, and how to fix it.

Validation is about syntax only. It confirms the document is well-formed; it does not check that email holds an email address or that a required field is present. That is JSON Schema, a separate layer built on top.

Why validate JSON?

Almost every JSON problem is a one-character problem, and almost every one of them surfaces somewhere unhelpful — a failed deployment, a 400 from an API, a config file that silently falls back to defaults. Validating first turns a vague failure into a line number.

  • Before sending a request. A malformed body usually comes back as a generic 400 with no detail, and looking that status code up only confirms the request was unacceptable, never which character caused it. Checking locally takes a second and tells you precisely what the server would have objected to.
  • After hand-editing a config file. Config is edited by hand more than anything else, and a stray comma can take a service down at the next restart rather than at the moment you saved.
  • When a parser blames the wrong place. An unclosed brace on line 12 is often reported at the end of the file, because that is the first point at which continuing becomes impossible. Seeing every problem at once makes the real cause obvious, and once the document parses the JSON viewer collapses it to a tree where the nesting you actually ended up with is easy to check.
  • To catch what parsers hide. Duplicate keys parse without complaint and silently discard data. Nothing in a normal pipeline will ever mention them.
  • When the JSON came from somewhere else. Copying out of a terminal, a browser console or a document introduces curly quotes, non-breaking spaces and byte order marks that are invisible in an editor.

Common JSON validation errors

Nearly every invalid document fails for one of these reasons. Each example below is rejected by any conforming parser, with the correction beside it.

Missing comma

Two properties sit next to each other with nothing between them. Every property in an object, and every item in an array, must be separated by a comma.

Invalid
{  "id": 1  "name": "Ada"}
Valid
{  "id": 1,  "name": "Ada"}

Missing quotation mark

A string is missing its opening quote, so the parser reads Ada as a bare word and rejects it. Strings and property names both need a double quote at each end.

Invalid
{  "id": 1,  "name": Ada"}
Valid
{  "id": 1,  "name": "Ada"}

Trailing comma

A comma follows the last property, promising another value that never arrives. JavaScript tolerates this; standard JSON does not.

Invalid
{  "id": 1,  "name": "Ada",}
Valid
{  "id": 1,  "name": "Ada"}

Invalid brackets

An array was opened with [ but closed with } — or never closed at all. Every bracket and brace must be closed by its own matching pair, in order.

Invalid
{  "tags": ["a", "b"}
Valid
{  "tags": ["a", "b"]}

Invalid escape character

Inside a string a backslash starts an escape sequence. Only \" \\ \/ \b \f \n \r \t and \uXXXX are valid, so a literal backslash has to be doubled.

Invalid
{  "path": "C:\Users\ada"}
Valid
{  "path": "C:\\Users\\ada"}

Unexpected token

True comes from Python and NaN from JavaScript. JSON recognises only the lower-case words true, false and null, and has no way to express a non-finite number.

Invalid
{  "active": True,  "score": NaN}
Valid
{  "active": true,  "score": null}

Duplicate keys

This parses, but ambiguously. The specification does not define which value wins, and in practice the last one silently replaces the first — so data disappears without an error.

Invalid
{  "id": 1,  "id": 2}
Valid
{  "id": 2}

How JSON validation works

  1. 1. The text is broken into tokens. Braces, brackets, colons, commas, strings, numbers and the three bare words true, false and null. Anything else is invalid on sight — this is where a single quote or a stray NaN is caught.
  2. 2. The tokens are checked against the grammar. A value, then optionally a comma and another value, until the container closes. The moment a token appears where the grammar does not allow it, the document is invalid and that position is the error position.
  3. 3. Everything after the first error is examined too. A fail-fast parser stops here, which forces you into a fix-one-rerun loop. This validator keeps reading so it can report every problem in one pass.
  4. 4. The document is checked against the chosen specification. RFC 4627 requires the top-level value to be an object or an array; RFC 8259 allows any value but expects UTF-8 with correctly paired surrogates. The same text can be valid under one and invalid under another.
  5. 5. Ambiguities are reported as warnings. Duplicate keys are legal but lossy, so they are flagged without failing the document.

One detail is worth internalising: the reported position is where the parser noticed the problem, not always where you made it. An unclosed brace is reported at the end of the file, because that is the first point at which it becomes impossible to continue. When the position looks wrong, the real mistake is usually earlier.

JSON validation best practices

  • Fix the first error first. One mistake early on frequently produces a cascade of later ones. Correct the top of the list and revalidate before working through the rest.
  • Validate in CI, not just by hand. A schema check on every commit catches the broken config before it reaches a server rather than after.
  • Treat duplicate keys as a bug in the producer. They parse, but the earlier value is discarded without warning. Whatever generated the document is doing something wrong.
  • Remember JSON is not JavaScript. Unquoted keys, single quotes, trailing commas, comments and undefined are all legal JavaScript and all invalid JSON. Never paste a JS object literal and expect it to validate.
  • Use UTF-8 without a byte order mark. RFC 8259 says implementations must not add one, and many parsers refuse to read past it.
  • Keep large identifiers as strings. JSON numbers are arbitrary precision on paper, but most parsers read them as 64-bit floats. An ID beyond 253 will quietly lose its last digits and still validate.
  • Validate before you format. Formatting a broken document just moves the problem around. Establish that it parses, then hand it to the JSON formatter to make it readable.

Frequently asked questions

Is this JSON Validator free?

Yes. Validation, error explanations, statistics, uploads and downloads are all free, with no account, no usage limit and no paid tier. There is nothing held back.

Is my JSON uploaded anywhere?

No. Validation runs in your browser using JavaScript. The JSON you paste, drop or upload is never sent over the network, never stored and never logged. Open your browser's network panel and you will see no request; disconnect from the internet after the page loads and the validator keeps working.

What counts as invalid JSON?

Anything the JSON grammar rejects: a missing or extra comma, a missing colon, an unquoted property name, a single-quoted string, a trailing comma, an unclosed bracket, an invalid escape sequence, a comment, or a value such as NaN or undefined that has no JSON equivalent. Valid JavaScript is frequently invalid JSON, which is where most surprises come from.

Why does the validator show several errors at once?

Most validators stop at the first problem, so fixing a document becomes a loop of correcting one error and running it again. This one parses the whole document even after it breaks, so you get every problem in one pass with next and previous controls to step through them.

How do I fix a JSON syntax error?

Start with the first reported error, since a single mistake early in a document often produces several later ones. Each problem here names what went wrong, the line and column it happened at, why it is not valid, and what to change. Click a problem to jump the cursor straight to it.

Can I validate large JSON files?

Yes. Documents up to roughly 20 MB are supported. Anything over about 120 KB is validated in a background Web Worker so the page stays responsive, and the editor only renders the lines currently on screen.

Can I upload a JSON file?

Yes. Use the upload button or drag a .json file anywhere onto the tool. The file is read locally with the browser's FileReader API and is not transmitted. Files up to 20 MB are accepted.

Does this validator detect duplicate keys?

Yes, and almost nothing else does. The specification permits duplicate names but does not define what they mean, so every parser quietly keeps the last one and discards the earlier value. Duplicates are reported as warnings with their path and line, because the document is ambiguous rather than broken.

What is the difference between validating and formatting JSON?

Validating answers whether the text is legal JSON and, if not, exactly where and why it breaks. Formatting rewrites valid JSON with consistent indentation so it is easier to read. If you want the document reformatted or repaired, the JSON Formatter does that; this tool concentrates on diagnosis.

Which JSON standard does it check against?

RFC 8259 by default, the current specification, which is what JSON.parse implements in browsers and Node.js. You can switch to RFC 7159, RFC 4627 or ECMA-404 in the options. The choice genuinely changes the verdict — RFC 4627 requires the top level to be an object or an array, so a bare string passes under 8259 and fails under 4627.

What does the encoding check look for?

RFC 8259 requires JSON exchanged between systems to be UTF-8 and warns that unpaired surrogate code points make behaviour unpredictable. The encoding check looks for lone surrogates, whether written raw or as \uD800-style escapes without their pair.

Are comments allowed in JSON?

No. Standard JSON has no comments, so // and /* */ are rejected by every conforming parser. Editors often accept them in configuration files under the name JSONC, but that is a different format. If a file needs explanation, add a property such as _comment.

Does the validator change my JSON?

Never. It only reads the document and reports on it. Your input is exactly what you typed, pasted or uploaded until you change it yourself.

Does it work offline?

Once the page has loaded, yes. All the validation is local, so you can disconnect and keep working. You only need a connection to load the page in the first place.

Why does my JSON work in JavaScript but fail here?

JavaScript object literals are far more permissive than JSON. Unquoted keys, single quotes, trailing commas, comments, hexadecimal numbers and values like undefined and NaN are all legal JavaScript and all invalid JSON. The validator names whichever one it finds so you can see which JavaScript habit crept in.

Popular tools

↑ ↓Navigate↵OpenEscClose