Guides
Find the exact character where your JSON breaks
"Unexpected token < in JSON at position 1" tells you almost nothing when position 1 is inside a 200 MB file. JSONParse reports the line, the column and the text around the failure.
What you get when a parse fails
- The byte offset of the offending character.
- The line and column, computed from a line-start table built during the scan.
- A description of what the parser expected at that point.
- The surrounding source, so you can see whether it is a truncated download, an HTML error page, a trailing comma or a smart quote.
The failures that actually happen
| Symptom | Usual cause |
|---|---|
Fails at position 0 or 1 with < | The response is an HTML error page, not JSON. Check the status code. |
| Fails near the very end | Truncated download or an interrupted write. Compare the byte count with Content-Length. |
Fails after a value, before } | A trailing comma — legal in JavaScript, not in JSON. |
| Fails on a string | A smart quote pasted from a document, or an unescaped control character. |
| Parses only the first object | The file is newline-delimited, not a single document. See JSONL. |
NaN, Infinity or undefined | A serialiser emitted JavaScript rather than JSON. |
Validating structure, not just syntax
Syntax validation answers "is this parseable". It does not answer "is this the right shape". For that, generate a JSON Schema from a document you trust and validate later documents against it in CI.
Open the viewerNo sign-up, no upload, no file size dialog.
Frequently asked questions
Does the validator stop at the first error?
Yes. JSON has no recovery rule that is safe to guess at — once a document is malformed, everything after the failure point is ambiguous. The first error is reported precisely rather than a list of speculative ones.
Can it validate against a JSON Schema?
Not in the viewer today. JSONParse generates a schema from a document; validating documents against an existing schema is best done with a dedicated validator such as Ajv in your build or test pipeline.
Why does my file validate here but fail in my application?
Most often the application is stricter about duplicate keys, very large integers, or a specific top-level type. It can also be reading the file with a different encoding — a UTF-8 BOM ahead of the opening brace breaks several parsers.
Last updated .