← Back to the JSON tool

JSON Validator

Last updated: 26 September 2026

Paste any text and find out in a split second whether it is valid JSON — and if it is not, which line and column break the parser and what usually causes it. Nothing leaves your browser.

How to use this validator

1. Copy the JSON you want to check — an API response, a config file, a fixture, a request body.
2. Paste it into the box above and press Validate JSON, or hit Ctrl/Cmd + Enter.
3. If it fails, read the reported line and column, then check the cause listed underneath. Most failures are one of the eleven mistakes in the next section.
4. Once it is valid, open the formatter to pretty-print it, or the minifier to shrink it.

What makes JSON invalid

JSON is a small, strict grammar. Almost every rejection comes down to one of these:

• Trailing comma — {"a": 1, "b": 2,}. JavaScript tolerates it in object literals; JSON does not allow a comma before the closing } or ].
• Single quotes — {'name': 'John'}. Strings and property names must use double quotes.
• Unquoted keys — {name: "John"}. Every property name has to be a quoted string.
• Comments — // … and /* … */ are not part of JSON. Files that need them are JSONC, which you must strip before parsing.
• Python-style literals — True, False, None. The JSON equivalents are true, false and null, all lowercase.
• NaN and Infinity — unrepresentable in JSON; serialise them as null or a string.
• Smart quotes — text pasted from a word processor or a slide deck arrives as “name” instead of "name".
• A raw newline inside a string — line breaks must be escaped as \n.
• Bad escapes — \d or a lone backslash in a Windows path ("C:\new"). Backslashes need doubling.
• NDJSON or concatenated objects — one JSON value per document, so {...}{...} or newline-delimited records will not parse as one value.
• An invisible byte-order mark — a UTF-8 BOM saved at the start of a file makes the very first token illegal.

Reading the error message

Browsers word parser errors differently, which is why the same file can produce three different messages, and some of those forms name no place at all. Newer Chrome and Safari report both an offset and a pair — at position 142 (line 5 column 12); older builds report only at position 142, an offset counted in characters; Firefox reports at line 5 column 12 directly. For a handful of errors, such as a trailing comma inside an array, Chrome quotes the surrounding text instead and gives neither number. This page converts all of those into a line, a column and a quoted snippet, and falls back to scanning your text for the mistakes listed above when the engine names no location, so you are not left counting characters by hand.

One trap worth knowing: the reported position is where parsing stopped, which is often a character or two after the actual mistake. A trailing comma is reported at the closing bracket, and a missing comma is reported at the token that follows it. Look slightly left of the caret.

Validate JSON from the command line

For files you cannot paste into a browser — CI checks, gigabyte exports — parse them locally instead. Each of these exits non-zero on invalid input, which makes them usable as a build step:

• python3 -m json.tool config.json > /dev/null — prints the error with a character offset.
• jq empty config.json — the shortest strict check, and it names the line and column.
• node -e "JSON.parse(require('fs').readFileSync(process.argv[1],'utf8'))" config.json — the same parser your application uses.

For a quick check of an HTTP response without saving it, pipe the request into one of them: curl -s https://api.example.com/status | jq empty.

What this validator does not do

It checks syntax, not meaning. It will not run JSON Schema checks, will not tell you a required field is missing, will not compare two documents, and will not repair broken input for you — a tool that silently “fixed” your JSON would only hide the mistake until it reached production. If you want the document restructured instead, that is the formatter's job.

Frequently Asked Questions