toooly-box

JSON Validator

Paste JSON and find out whether it parses, and if not, exactly where it stops.

runs locally
JSON validator
Paste your JSON
Not valid JSONLine 4, column 1: Expected double-quoted property name in JSON at position 54 (line 4 column 1)
}
^

What is a JSON validator?

A JSON validator answers one question: will this text parse as JSON? If it will not, it names the line and column where the parser gave up and what it expected there. Valid is not the same as correct: a validator checks the syntax, never whether the values make sense.

How it works

The validator hands your text to the browser’s own JSON parser, the same one your code will use. If the parser accepts it, it is valid JSON by definition; there is no second opinion to get.

When it fails, the parser reports the character offset where it gave up. That offset is turned into a line and a column, and the offending line is printed with a caret under the column, the way a compiler points at an error.

The position is where the parser noticed the problem, which is always at or after the mistake. A missing closing brace is reported at the end of the file, because that is where the parser ran out of input.

What is valid JSON

JSON is a small format, and the specification (ECMA-404, and RFC 8259) fits on a few pages. A valid JSON document is one value: an object, an array, a string, a number, true, false or null. Everything else is a syntax error, and a JSON validator is a tool that answers that one question without you having to run your code to find out.

The strictness is the point. JSON was deliberately made smaller than the JavaScript object literals it resembles, so that a parser in any language accepts exactly the same documents. That is also why a file that looks obviously fine to a human, and that your editor syntax-highlights without complaint, can still be rejected: the rules are narrower than they look.

What JSON does not allow, and the errors each produces

  • Comments neither // nor /* */. Configuration files are the usual victim; JSONC, JSON5 and the config dialects of some tools add them back, but plain JSON parsers reject them with "Unexpected token /".
  • A trailing comma a comma after the last element of an object or an array. This is the single most common cause of invalid JSON, and it comes from hand-editing. The error points at the closing brace or bracket.
  • Single quotes 'name' is not a string. JSON strings use double quotes, always, for keys as well as values.
  • Unquoted keys {name: "x"} is valid JavaScript and invalid JSON. Every key is a quoted string.
  • NaN, Infinity and undefined there is no way to write them. A serialiser that emits NaN has produced something no JSON parser will read back; use null, or a string, or restructure the field.
  • A real newline inside a string a line break between quotes must be the escape \n. Pasting a multi-line value out of a terminal is how this gets in.
  • A leading zero or a hex number 0x1F and 007 are not JSON numbers. Write 31 and 7.

Reading the position the parser gives you

The line and column mark where the parser stopped, not where you made the mistake. The two are the same for a stray character, and far apart for anything unbalanced: forget a closing brace on line 12 of a 400-line file and the error lands on line 400, because the parser kept reading happily until it ran out of document.

So when the reported position is the very end of the file, suspect something unclosed above it: a brace, a bracket, or a string whose closing quote is missing. When the position is in the middle, read the few characters immediately before it: that is where the invalid token begins. An error on a line that looks perfect usually means the previous line is missing its comma.

Validator or formatter?

They are the same check seen from two sides, because formatting requires parsing. Use the validator when you want the verdict and the position and nothing else: checking a config file before a deploy, or confirming that an API response is well-formed before you go looking for a bug in your own code. Use the JSON formatter when you want to read the document, indent it, sort its keys or minify it.

Neither one validates against a schema. "Valid JSON" means the syntax parses; it says nothing about whether the field you need is present, whether the id is a string or a number, or whether the date is in the format the other system expects. That is JSON Schema’s job, and it is a different, larger question.

Checking a file you should not upload

The parse runs in the page, in your browser, with the same engine that runs the rest of the site. Nothing is sent anywhere, so the API response with a customer record in it, the Kubernetes manifest with a secret reference, the export from a production database: all of them can be checked without any of them leaving your machine, and the tool keeps working with the network off.

That matters more than it sounds. An online validator that posts to a backend has received your document, and whatever it logs, it keeps. For anything from a production system, a check that happens locally is not a nicety; it is the only version of the tool you are allowed to use.

Questions people ask

Is my JSON sent to a server?

No. The parse happens in your browser with its own JSON engine, so nothing is uploaded and the tool works offline. You can paste production data safely.

Is my JSON valid?

Paste it above and you have the answer immediately: valid JSON is reported as valid, and anything else is reported with the line and column where the parser stopped. Validity here means the syntax parses, which is a different question from whether the data inside it is the data you meant.

Why does the error point at the last line of my file?

Because something above it was never closed: usually a brace, a bracket or a string. The parser kept reading until the document ran out, and reported the failure where it stopped, not where the mistake is.

Can JSON have comments?

No. Neither // nor /* */ is allowed, which is why a hand-edited config file so often fails. Formats such as JSONC and JSON5 add comments back, but a plain JSON parser rejects them.

Does valid JSON mean my data is correct?

No. It means the syntax parses. Whether the required fields are present and the types are right is schema validation, a separate check: JSON Schema is the usual tool for it.