JSON validation means confirming that a document strictly conforms to the ECMA-404 and RFC 8259 grammar, returning either a green "valid" verdict or the exact line and column where parsing failed. To validate JSON reliably, paste the document into a tool that uses the same parser your runtime does, read the verdict, and fix any reported position before shipping. This is different from prettifying the file: a validator leaves your text alone and only answers one question — is this JSON well-formed, and if not, where exactly does it break? Modern browsers ship a native JSON.parse implementation that is already RFC 8259 compliant, which is why a browser-based checker such as the JSON Validator gives the same verdict as Node.js, Python's json module, or any standard library in production. The tool also reports a structural fingerprint — top-level type, maximum nesting depth, total keys, and counts of objects and arrays — so you can sanity-check the shape of an API response, config file, or generated payload in the same step.
What Counts as Valid JSON
Standard JSON is defined by RFC 8259, which sets the lexical and structural rules every parser follows. A document passes validation only when it obeys that grammar exactly: objects delimited by curly braces, arrays by square brackets, every key and every string value wrapped in double quotes, numbers written in a fixed lexical form, and true, false, and null as the only allowed literals. There is no provision for comments, no allowance for single quotes, and no special handling of NaN or Infinity. The browser's native JSON.parse implements this same grammar, which is why a validator built on it returns the verdict your JavaScript runtime, Node.js process, and most JSON libraries will reproduce — no lenient guessing, no auto-repair, no silent tolerance. That strictness is the entire point: if you can parse it locally, you know any conforming consumer in production can parse it too.
The Most Common JSON Syntax Mistakes
Almost every "this JSON looks fine" failure comes from one of a handful of grammar violations. The errors below are the ones the validator surfaces with a precise position, because they are exactly what the RFC 8259 grammar rejects. A single object that pairs an unquoted key, single-quoted string values, a trailing comma after the last array element, a JavaScript-style line comment, and a large integer — that snippet packs five distinct violations the parser will refuse to tolerate, all caught in one validation pass.
| Mistake | Why it fails | Quick fix |
|---|---|---|
| Single quotes around a string or key | RFC 8259 requires double quotes for every string | Replace with " |
| Unquoted object key | Keys are strings, and strings must be quoted | Wrap the key in "…" |
| Trailing comma after the last array or object element | The grammar terminates before a trailing comma | Delete the comma |
| Comment using // or /* */ | JSON has no comment syntax | Remove the comment |
| NaN or Infinity as a number | Not part of the JSON number grammar | Use null or a quoted string instead |
| Unbalanced bracket or brace | Every opening token must have a matching closer | Count tokens and pair them up |
When the parser hits one of these, it stops at the offending character and reports a position. Browsers word the message slightly differently — V8 in Chrome and Edge, SpiderMonkey in Firefox, JavaScriptCore in Safari — but the coordinates the JSON Validator returns are normalized from whichever format the engine reports.
Validate a JSON Document Step by Step
The fastest way to validate JSON and act on the result is a tight three-step loop: paste, read the verdict, fix the reported position.
- Paste or type your JSON into the input box.
- Read the verdict instantly: a green "Valid JSON" message, or a red error block that includes the exact line and column where parsing failed.
- For valid JSON, review the structure report — top-level type, maximum depth, total keys — to sanity-check the shape of your data.
If the verdict is red, jump straight to the reported line and column in your editor; the parser stopped exactly there, and the message names the token it did not expect. Make the smallest fix the grammar allows, paste the corrected document back in, and re-run the same check. Repeating the loop is intentional: each pass narrows the failure to the next grammar violation, which is why a validator that returns a position is far more useful than one that only returns "syntax error".
Reading Error Positions From Different Browsers
The parser's own error message is the most reliable guide to what went wrong, because it is produced by the same engine your application will run on. Different engines phrase things differently, though, and that is where a tool that normalizes the output becomes useful. V8 in Chrome and Edge tends to report messages like "Unexpected token } in JSON at position 42", with a single byte offset into the document. SpiderMonkey in Firefox reports something closer to "JSON.parse: expected property name or '}' at line 3 column 7 of the JSON data", giving a line and column directly. JavaScriptCore in Safari follows a similar line-and-column format with its own wording. The JSON Validator surfaces the parser's own message and, wherever the engine provides it, the precise line and column of the failure — for example "Invalid JSON at line 3, column 7." That turns a vague "unexpected token" into a position you can jump straight to in your editor.
What the Structure Report Tells You
A green verdict only proves the text is well-formed. It says nothing about whether the shape matches what your code expects. The structure report fills that gap by listing facts about the document itself.
| Field | What it means |
|---|---|
| Top-level type | One of object, array, string, number, boolean, or null |
| Maximum depth | The deepest level of nesting, useful for catching accidentally recursive structures |
| Total key count | Sum of every object key at every level |
| Object count | How many {…} blocks appear in the document |
| Array count | How many […] blocks appear in the document |
| Character count | The length of the document as pasted |
These numbers are quick sanity checks. A response that should be a flat array of users but reports a maximum depth of nine is a sign something has been wrapped or escaped. A config file that returns thousands of keys when you expected a handful is a sign a duplicate payload has been merged in. The same report also helps confirm a payload's size before shipping it over a slow link.
Validator vs. Formatter: Different Jobs
A validator and a formatter answer different questions. A JSON formatter beautifies or minifies your document so a human can read it or a payload can be compressed; many formatters include a validity check as a side effect. A validator deliberately leaves the text unchanged and reports only correctness, error position, and structural stats. Use the validator when the file came from somewhere you do not trust — an upstream API, an export tool, a copy-paste from documentation — and you need to confirm it will parse before your code touches it. Use the formatter when the file is already known to be valid and you need to read it, diff it, or shrink it. The same document can be run through both, in either order.
A Caveat: What Validation Does Not Catch
A green verdict confirms syntax, not semantics. Two practical limits are worth knowing. First, JSON numbers are parsed as IEEE-754 doubles, so integer values beyond 2^53 lose precision — a 64-bit identifier copied through JSON.parse can come out as a different number. Second, JSON validation does not enforce a schema: a document can be perfectly well-formed and still be the wrong shape for the field you are filling in. For schema-level checks, pair syntax validation with a JSON Schema validator that knows the contract your data is supposed to satisfy. Validation runs entirely in your browser, on the engine's native parser, so even large or deeply nested input is processed safely without uploading anything to a server.