DevLab
{}
JSON⭐ Popularbeginner

JSON Validator

validate JSON and show specific error locations

By Bikram NathLast updated

Paste any JSON string and the validator pinpoints the exact line and column where parsing fails, telling you whether the problem is a missing comma, an unquoted key, or a trailing comma after the last array element. Feed it a 400-line API response that crashes your fetch handler and you get 'Unexpected token } at line 23, column 4' instead of a generic SyntaxError. Unlike a formatter that silently fixes input, this tool only reports — it never mutates.

Try it now — free, instant, no signup

What is JSON Validator?

JSON Validator runs your input through the browser's native JSON.parse() and, when that throws, extracts the error position from the exception message to highlight the exact offending token. Paste a config file with a trailing comma after the last key, and you see the line number immediately rather than hunting through 300 lines of minified text.

Developers reach for this instead of JSONLint when they want results without a round-trip to an external server, or instead of piping through jq locally when they are already in a browser tab. jq is better for querying and transforming; this tool is better when the only question is 'is this valid JSON and if not, where exactly is it broken.'

One practical gotcha: JSON.parse() stops at the first error, so fixing one problem may reveal another you did not know was there. Run the validator again after each fix. Also note that JSON5 and HJSON, which allow comments and trailing commas, will always fail standard JSON validation — if your file uses those formats, you need a dedicated parser before treating the output here as authoritative.

When to use JSON Validator

Validate a webhook payload that returns HTTP 200 but causes a JSON.parse crash inside your event handler.
Check a hand-edited .json config before pushing to a branch where CI will reject it with an unhelpful error.
Confirm that a third-party API response is spec-compliant JSON before writing a deserializer against it.

Frequently Asked Questions

The validator says my JSON is invalid but JSON.parse() in Node accepts it — why?
Node's JSON.parse() is spec-compliant and should reject the same input this tool rejects. The most common explanation is that your Node code is not actually calling JSON.parse() on the raw string — it may be using a library like json5 or a YAML parser that accepts a superset of JSON. Another possibility is that you are testing a different string in Node than the one you pasted here, for example one that has already had escape sequences resolved by your shell or terminal before it reached Node.
What is the largest JSON input this tool can handle in the browser?
Chrome and Firefox impose a string length cap that V8 enforces at roughly 512 MB, but the practical browser tab limit is much lower because JSON.parse() needs to allocate the parsed object tree in addition to the raw string. In practice, inputs above 10 to 20 MB will cause the tab to slow noticeably or freeze. For large JSON files, jq on the command line or a streaming parser like stream-json in Node will handle multi-gigabyte input that a browser-based tool cannot.
Why does the error message say 'Unexpected token' at a line that looks fine to me?
JSON errors are positional and the parser reports where it gave up, not necessarily where the actual mistake is. A missing closing quote on line 10, for example, will cause the parser to consume all text until it hits something that cannot be part of a string, which might be a comma or brace on line 15. Look at the few lines immediately before the reported position, not just the line itself. Missing commas between object keys are the other common case where the reported position is one token ahead of the real problem.
Can this validator catch duplicate keys in a JSON object?
No. Duplicate keys are technically permitted by the JSON spec (RFC 8259, section 4 says names 'SHOULD' be unique but does not prohibit duplicates), so JSON.parse() does not throw on them. Most parsers, including V8, silently keep the last value for a duplicated key. If you need to detect duplicates, a linting tool like eslint with the json plugin, or a custom walk of the parsed AST, is the right approach. This validator only checks structural syntax, not semantic rules like key uniqueness.
How is this different from using the Network tab in Chrome DevTools to inspect a JSON response?
The DevTools Network tab shows you a parsed, pretty-printed tree if the Content-Type is application/json, but it does not give you a character-level error position when the JSON is malformed. If the server returns invalid JSON, DevTools shows the raw text and the console logs a generic parse error. Pasting the raw response body here gives you the exact line and column of the syntax error, which is more actionable when you are debugging a backend that is emitting subtly broken JSON.

Related Tools