Paste JSON and find out immediately whether it parses — and if it does not, exactly where and why. Every problem gets a line and column, a highlighted excerpt of your text, and an explanation written for humans: trailing commas, single quotes, unquoted keys, comments, NaN and undefined, Python's True and None, leading zeros, curly quotes pasted from a word processor, and invisible characters copied from web pages. Valid JSON still gets checked for duplicate keys, integers too large for JavaScript, and extreme nesting.
Validation runs entirely in your browser, so API responses and config files never leave your machine. Once your JSON is valid, the JSON formatter can minify or re-indent it, the JSON Schema validator checks that it has the right structure, and the NDJSON formatter handles files with one JSON record per line.
Frequently asked questions
Why does my JSON fail with a trailing comma?
The JSON specification (RFC 8259) does not allow a comma after the last item in an object or array, so {"a": 1,} and [1, 2,] are invalid even though JavaScript, Python, and JSON5 all accept them. It is the single most common JSON error, usually left behind after deleting the last line of a list. The validator points at the comma itself rather than the closing bracket, so you can delete it directly. If your file is a tsconfig.json or VS Code settings file, those use JSONC, which tolerates trailing commas and comments — but any tool that expects plain JSON will reject it.
Can JSON have comments?
No. Standard JSON has no comment syntax at all — not //, not /* */, and not #. Douglas Crockford removed comments deliberately to keep parsers simple and interoperable. Some tools accept a superset called JSONC (JSON with comments), used by TypeScript and VS Code, and JSON5 goes further with unquoted keys and single quotes. This validator checks strict JSON, so it flags comments and tells you when the input looks like JSONC or JSON5. If you need notes inside real JSON, a common convention is a "_comment" field that consumers ignore.
Why is my large ID number changing after parsing?
JSON itself allows integers of any size, but JavaScript (and every parser that stores numbers as 64-bit floats) can only represent integers exactly up to 2^53 − 1, which is 9,007,199,254,740,991. Anything bigger is silently rounded to the nearest representable value with no error: 12345678901234567890 is stored as exactly 12345678901234567168, which JavaScript prints as 12345678901234567000 (the shortest decimal that maps back to the same float). The validator’s warning shows the exact stored value. That is how database IDs, Twitter/X snowflake IDs, and big money amounts get corrupted between services. The validator warns about each such number even when the JSON is valid. The fix is to send those values as strings ("id": "12345678901234567890"), which is what most large APIs do.
Does valid JSON mean my data is correct?
No — valid JSON only means the syntax parses. The validator also warns about things the parser silently accepts but that usually indicate bugs: duplicate keys (JSON.parse keeps only the last one, discarding earlier values without telling you), numbers too large to survive parsing, and nesting deeper than 100 levels, which some parsers and APIs refuse. To check that the data has the right shape — required fields, types, allowed values — you need a JSON Schema, which you can check with our JSON Schema validator.
How does the validator find the exact line and column?
Browsers report JSON errors inconsistently: Chrome gives a character position, Firefox a line and column, and Safari often gives no location at all. So instead of relying on the browser message, the validator runs its own strict scanner over your text that follows the JSON grammar exactly. When it hits a mistake it can recognize — a trailing comma, a comment, a single quote — it records the problem with a plain-English explanation and keeps going, so you can often fix several errors in one pass. It stops at the first problem it cannot safely skip, and it never sends your data anywhere.
My file has one JSON object per line. Why is it invalid?
A JSON document must contain exactly one top-level value, so several objects one after another — {"a":1} on line 1, {"a":2} on line 2 — are invalid JSON. That layout is a different format called NDJSON or JSON Lines, widely used for logs, data exports, and machine-learning datasets because each line can be read independently. The validator detects the second value and suggests the NDJSON tool, which validates each line separately and can convert the file into a single JSON array. Alternatively, wrap the objects in [ ] and separate them with commas to make one valid JSON array.