JSON Validator with Error Line Numbers
Validate JSON in your browser and see the exact failing line number, plus two-space formatting when the document parses. Nothing is uploaded.
Loading tool…
How It Works
A JSON validator with error line numbers answers one question quickly: does this document parse, and if not, which line do I fix? This page runs the browser's own JSON parser, which implements RFC 8259, so anything it rejects is genuinely invalid JSON rather than a disagreement between two linters.
Validation step. The text is passed to JSON.parse inside a try/catch. A successful call means the document is well formed; the same call also produces the value, which is re-serialised with two spaces of indentation so you get a readable copy alongside the verdict. A thrown SyntaxError is caught and turned into an error message, never an uncaught exception.
Line numbers. Engines report failures differently. V8, used by Chrome and Edge, ends its message with "at position N (line L column C)", so the line is read straight from the message. Firefox reports only a position, so the validator counts the newline characters before that offset and adds one. When neither pattern appears, no line number is shown instead of a guessed one.
What gets flagged. Everything outside the grammar: unquoted keys, single-quoted strings, trailing commas, comments, missing commas between properties, unbalanced brackets and unterminated strings. Because parsing stops at the first failure, you get one error per run, and repairing it usually reveals the next one if the document has several.
Why one error at a time is enough. Later failures are normally consequences of the first: a missing brace at the top of a config file makes every closing brace below it look wrong. Fixing the earliest reported line and re-running therefore converges faster than reading a list of cascading complaints.
The check runs entirely in the page, so API payloads, credentials embedded in config files and customer data never leave the browser, which matters when the document you are debugging is a production response rather than a test fixture.
How to repair a document using the reported line
- Paste the whole document, braces included; the check runs on every edit, so there is no submit button to press.
- Read the line number in brackets after the message. It is a one-based line, not a character offset, so it matches what your editor shows.
- Inspect one line above that number first, because a missing comma is detected at the token that should have followed it.
- Fix that single fault and paste again: only the first syntax error is reported, so a second one appears only after the first is gone.
- When the message disappears the document parses, and the output pane shows the same value re-indented with two spaces.
Common faults and what the validator reports
| Broken input | Message (position text trimmed) | Line reported |
|---|---|---|
| {"a":1,} | Expected double-quoted property name in JSON … | 1 |
| {a:1} | Expected property name or '}' in JSON … | 1 |
| {'a':1} | Expected property name or '}' in JSON … | 1 |
| [1,2 | Expected ',' or ']' after array element in JSON … | 1 |
| { "a": 1 "b": 2 } | Expected ',' or '}' after property value in JSON … | 3 |
Examples
Input
{
"a": 1,
}Output
Expected double-quoted property name in JSON at position 12 (line 3 column 1) (line 3)A trailing comma after the last property. The engine names line 3 and the validator repeats it in brackets.
Input
{
"a": 1
"b": 2
}Output
Expected ',' or '}' after property value in JSON at position 13 (line 3 column 3) (line 3)A missing comma between two properties is detected at the next token, so the reported number is one higher than the line that needs the fix.
Input
Output
Empty inputBoundary case: an empty document is rejected before parsing, with no line number, because there is nothing to point at.
Frequently Asked Questions
- Why does the error point at a line that looks correct?
- Parsers report where they noticed the problem, not where it started. A missing comma on line 2 is often detected on line 3, at the token that should have followed it. Read one line above the reported number first, and if that line is fine, look for an unclosed quote or bracket further up.
- Does it validate against a JSON Schema?
- No. It checks syntax only: brackets, quotes, commas and value types the grammar allows. A document can be perfectly valid JSON and still be wrong for your API, because a required field is missing or a number arrives as a string. Schema validation is a separate step that needs the schema definition.
- Can it find duplicate keys?
- No, and neither can any strict parser. JSON does not forbid a repeated key, so the last value silently wins and the document stays valid. If duplicate keys would break your application, check for them with a dedicated linter, because this validator will report the document as correct.
- Is the JSON uploaded anywhere?
- No. Parsing happens in your browser tab with the built-in engine, so nothing is sent over the network and nothing is stored. You can confirm it by switching the browser to offline mode after the page has loaded: validation keeps working with no connection at all.
Limitations & Accuracy
Only the first syntax error is reported, so a document with several faults needs one run per fix. The wording of the message comes from your browser engine, and V8 and Firefox phrase it differently, so the line number is the stable part. The reported line is where the parser noticed the problem, which can be one line after the actual fault. Numbers above 9007199254740991 are rounded silently because JSON.parse returns doubles, and duplicate keys are accepted with the last value winning.