JSON Validator Online - Real-time JSON Syntax Checker
Updated
Validate JSON data against standards. Get exact line numbers and detailed error messages for syntax violations in your JSON files. 100% Private & Free.
What it does with tricky input
Each row is an automated test: the tool's own code runs on the input before every release, and the release stops if the result changes. Error text is what Chrome prints; Firefox and Safari word some errors differently. More on how we test.
| Case | Input | Result |
|---|---|---|
| A trailing commaColumn 8 is the } after the comma. JSON Repair removes the comma. | Input{"a":1,} | ResultError at line 1, column 8: Expected double-quoted property name. There is a comma before a closing bracket. Remove it, or let JSON Repair do it. |
| A missing comma between linesPoints at line 3, where "b" starts. | Input{\n "a": 1\n "b": 2\n} | ResultError at line 3, column 3: Expected ',' or '}' after property value. A comma is missing between two values (often at the end of the line above). |
| Single quotes | Input{'a':1} | ResultError at line 1, column 2: Expected property name or '}'. JSON needs double quotes around names and strings. JSON Repair can fix single quotes. |
| NaN | Input{"a":NaN} | ResultError at line 1, column 6: Unexpected token 'N'. NaN, Infinity and undefined are not JSON values. Use null, a number or a string. |
| A // commentJSON has no comments. JSON Repair strips them. | Input{"a":1 // note\n} | ResultError at line 1, column 8: Expected ',' or '}' after property value. JSON does not allow comments. JSON Repair can strip them. |
| A byte order mark (BOM) at the startExplained in words instead of "Unexpected token". | Input[BOM]{"a":1} | ResultError at line 1, column 1: The text starts with an invisible byte order mark (BOM, U+FEFF), which JSON.parse rejects. Save the file as UTF-8 without BOM, or strip the first character before parsing. |
| A duplicate keyValid JSON, but most parsers keep only the last value. | Input{"a":1,"a":2} | ResultValid, with a warning at line 1, column 8: Duplicate key 'a' — most parsers keep only the last value |
| An ID past 2^53Valid JSON that JavaScript would round. | Input{"id":12345678901234567890} | ResultValid, with a warning at line 1, column 7: Integer 12345678901234567890 exceeds 2^53 and will lose precision — send it as a string |
Key Features
- ✅ Real-time validation
- ✅ Error line highlighting
- ✅ Detailed error reports
- ✅ Exact line/column error location
- ✅ One-click Format and Minify
How to Use
- Load your JSON via paste or upload
- The validator runs automatically on every change
- Read the parse error and line/column pointer shown in the right-hand output panel
- Fix the highlighted issues until the "Valid" indicator appears
Expert FAQ
- Why does my JSON fail here but work fine in JavaScript?
JavaScript object literals and JSON are not the same grammar. JS allows unquoted keys, single-quoted strings, trailing commas, and comments — none of which are legal in strict JSON (RFC 8259). This validator enforces the strict spec, so code that works as a JS literal (or with a lenient parser like JSON5) will correctly fail here if it relies on any of those JS-only conveniences. That's the point: catching exactly the cases that will break `JSON.parse()` or a strict backend parser in production. - My JSON has a number like 9223372036854775807 and it "loses precision" after I round-trip it — is that a validator bug?
No — this is inherent to JSON itself. The spec doesn't define an integer type with arbitrary precision; most parsers (including JavaScript's) decode JSON numbers as 64-bit floats, which only safely represent integers up to 2^53. Values larger than that (common with 64-bit database IDs, Snowflake/Twitter-style IDs) silently lose precision on decode. The fix is upstream: serialize large IDs as JSON strings, not numbers, if exact round-tripping matters. - Does it catch duplicate keys in the same object?
Yes, with a warning — duplicate keys are technically not forbidden by the JSON grammar itself (the spec is silent on it), but every real-world parser resolves them differently: some keep the first occurrence, most (including JavaScript) keep the last. Since this is a frequent source of "works on my machine" bugs when JSON is generated by string concatenation, the validator flags duplicate keys even though strict grammar validation alone wouldn't reject them. - It says my JSON is valid, but my API still rejects it — why?
Syntax validity and schema validity are different checks. This tool confirms your JSON parses correctly per the JSON grammar; it does not check whether the right fields are present, whether types match what an API expects, or whether values satisfy business rules (e.g. an enum field, a required nested object). For that, you need schema validation (JSON Schema) against your specific API contract — syntactic validity is a necessary but not sufficient condition.
Technical Details
JSON validation means checking input against the JSON grammar defined in RFC 8259 — correctly matched braces/brackets, properly quoted (double-quote only) string keys and values, no trailing commas, no unquoted keys, and numbers that match JSON's specific numeric grammar (no leading zeros, no hex literals, no NaN/Infinity, unlike JavaScript number literals). The validator reports the exact line and column where the parser's expectations diverge from the input, since "unexpected token" with no location is the single most useless error message in JSON tooling. A few edge cases are worth understanding rather than just fixing blindly: large integers beyond 2^53 silently lose precision in any standard JSON decoder because JSON doesn't mandate arbitrary-precision integers, so 64-bit IDs should be transmitted as strings if exact values matter downstream. Duplicate object keys aren't actually forbidden by the grammar — different parsers resolve collisions differently (first-wins vs last-wins) — so this validator flags them as a likely-unintentional pattern even though they don't make the document strictly invalid. Validity is also a narrower guarantee than correctness: a syntactically valid document can still violate an API's expected shape (wrong field types, missing required keys). For that level of checking, JSON Schema validation is the right tool — this validator answers "will JSON.parse() throw," not "does this match my contract." Once your JSON parses cleanly, use the JSON Formatter to make structural review easier, or JSON Compare to diff it against a known-good reference.