JSON Validator

What a JSON validator actually tells you

You ran a deploy, the service came up, and one request came back with SyntaxError: Expected double-quoted property name in JSON at position 35. That message is accurate and nearly useless, because position 35 is a character offset into the whole document and your editor counts in lines. Paste the same text here and you get Line 3, Column 3 — the same fault, expressed in the coordinates you can actually navigate to — along with the parser's own sentence so you can match it against the one in your logs.

Worth knowing before you use any validator: "valid JSON" is a wider category than most people assume. RFC 8259 §2 says a JSON text is any value, so "Reykjavik", 123, true and null are each complete documents on their own — you do not need an object or an array at the top. Several validators get that wrong and report a bare string as broken. This one does not, and it also peels a second layer when a document turns out to be a stringified document, which is what "{\"qci\":9}" is and what you get when something in the chain called stringify twice. The grammar behind all of this is short enough to read in one sitting on json.org.

How to use it

1. Paste or upload – Drop the document into the left pane, or use Upload for a .json file. Nothing is sent anywhere — the parse runs in the page.
2. Read the verdict – Checking runs about 300ms after your last keystroke, so there is no button. Valid documents get a size/lines/depth/keys summary; broken ones get a line, a column and the parser message.
3. Jump to the line – The reported line is tinted in the editor and carries a gutter marker, so you can scroll to it rather than counting rows.
4. Fix, then look again – A parser stops at the first fault, so one error does not mean one problem. Correct it and the check re-runs immediately — if a second fault existed, it appears now.
5. Tidy the result – Once the document parses, Format re-indents it at two spaces and Minify strips the whitespace. Both rewrite the pane in place and re-validate.

One thing that catches people out: a trailing comma is reported at the closing brace, not at the comma. Delete the comma on the line the error points near, not the brace on the line it points at.

A worked example

This is the document behind the Invalid Sample button, so you can click it and compare. It carries two separate faults — a single-quoted key on line 3 and a trailing comma on line 5 — and the panel reports exactly one of them, because that is where the parser stopped.

{
  "subscriberId": "SUB-77821",
  'apn': "internet.mno.com",
  "qci": 9,
  "pdpType": "IPv4v6",
}

✗ Invalid JSON

Line 3, Column 3
Error: Expected double-quoted property
name in JSON at position 35 (line 3
column 3)

The trailing comma on line 5 is not
mentioned. Fix line 3 and it becomes:

Error: Expected double-quoted property
name in JSON at position 97 (line 6
column 1)

When you would reach for this

Turning a byte offset into a line number

Node, Python and Go all report the offset differently and none of them is a line number. Node says at position 35, Python's json.decoder.JSONDecodeError says char 35 alongside a line and column, and Go's encoding/json reports offset 35 with no line at all. Pasting the payload here normalises the three into one answer. It is also the fastest way to check whether the offset in the log even matches the file you are looking at — if the document is shorter than the offset, you are debugging the wrong copy.

Confirming a config file before it ships

A malformed tsconfig.json, package.json or ESLint config fails at start-up, often with a message from a wrapper rather than the parser. Check it here first. One caveat that costs people an afternoon: tsconfig.json and VS Code's settings files are JSON with Comments, not JSON — a // line is legal there and will be reported as an error here. That is the validator being right about JSON, not wrong about your file.

Sanity-checking a payload that carries long identifiers

Telecom and finance payloads are full of 18- and 19-digit values — an ICCID such as 8901240544102066246, a card BIN, a Snowflake ID. Most validators parse into JavaScript numbers to inspect the document, which quietly rounds that to 8901240544102066000; you would not see it here anyway, but it means the size and key counts they print describe a document you did not paste. This page keeps the digits as written, which is the same care the JSON Formatter and JSON to Table take. MDN's JSON.parse reference spells out where the limit comes from.

What the panel shows

• Line and column, not an offset – the parser's character position is resolved against your text before it is shown.
• The parser's own sentence – shown as-is, so it matches what your terminal printed. Only Firefox's JSON.parse: prefix is trimmed.
• The failing line is tinted – plus a gutter marker at the reported column, so you do not count rows by hand.
• Size, lines, depth, key count – size is the bytes of the document exactly as it sits in the editor, so it agrees with the line count beside it. Depth and total keys are read from the parsed structure.
• Bare values and double-encoded strings accepted – "Reykjavik" validates; so does "{\"qci\":9}", and its contents are what the depth and key figures describe.
• Format and Minify on a valid document – two-space re-indent, or everything on one line. Long integers survive both.

Questions people actually ask

Why does it report one error when I can see three?

Because JSON.parse is a parser, not a linter: it stops at the first construct it cannot continue past and throws. The worked example above is the demonstration — fix the single-quoted key and the trailing comma appears as a fresh error at line 6 column 1. If you would rather have the punctuation repaired in one pass, the JSON Fixer is the page for that.

Is a bare string really valid JSON?

Yes, since 2014. The original RFC 4627 required an object or an array at the top level; RFC 8259 replaced it and allows any value, which is why JSON.parse('"hello"') works in every current runtime. Some older server-side validators still enforce the 2006 rule, so if a document passes here and fails there, that difference is usually the reason.

It says my document is valid, but my app still rejects it.

Then the problem is shape rather than syntax — a missing required field, a string where a number was expected, an enum value nothing recognises. Syntax validation cannot see any of that. JSON Schema is the tool for the next layer, and our JSON Schema Validator will check a document against one.

How big a file can I paste?

Big enough for anything you would read on screen. The parse itself is one JSON.parse call and is not the slow part; what does get uncomfortable is the editor rendering a multi-megabyte document while you scroll it. Past a few megabytes you are usually better off finding the one broken record and pasting that instead of the whole export.

What's the difference between validating and formatting?

Validation answers "does this parse". Formatting changes the whitespace of something that already parses. This page does both — Format and Minify appear once the document is valid — and the JSON Formatter is the dedicated page if reformatting is the whole job.

Does the check run on my machine?

Yes. The parse happens in your browser and neither the document nor any part of it is uploaded, cached or logged. Nothing on this page makes a network request while you type.

Related Tools

Useful Resources

• RFC 8259 – The current JSON specification. Section 2 is the one that makes a bare string a valid document.
• JSON.org – The grammar as railroad diagrams — quicker to scan than the RFC when you just need the shape of a rule.
• JSON Schema – For validating structure and types rather than syntax.
• Stack Overflow: json – Where most parser messages have already been asked about verbatim.