Two different parsers are watching your JSON, and they do not agree
While you type, a live linter underlines problems directly in the editor gutter — but that linter is a separate, more forgiving parser from the one the Validate & Format and Minify buttons actually run. The live linter tolerates // and /* */ comments inside your JSON and shows no warning for them at all; the moment you click Validate & Format, the tool runs the browser's own strict JSON.parse, which has no concept of comments and rejects the same text immediately. Text that looks clean in the editor can still fail the instant you click the button — that gap is a property of using two different grammars for two different jobs, not a bug in either one.
What the strict grammar accepts and rejects
Validate & Format and Minify both run on the real JSON grammar (RFC 8259 / ECMA-404), which is stricter than what many people expect from experience with JavaScript object literals. It rejects a trailing comma after the last item in an object or array, unquoted or single-quoted keys and string values, comments of any kind, and the special JavaScript numeric values NaN and Infinity — none of those are valid JSON, no matter how often they appear in hand-written config files. The live gutter linter catches the trailing comma, the unquoted key, and the single-quoted key the same way Validate & Format does; comments are the one case where it disagrees, tolerating what the strict parser will still reject.
Duplicate keys are never rejected — the last one silently wins
Paste {"role": "admin", "role": "guest"} and nothing here flags it as an error, in the editor or after clicking Validate & Format: JavaScript's JSON.parse keeps whichever value for a repeated key appears last and simply discards the earlier one, so the object that comes back has a single role field holding "guest". This is standard JSON.parse behavior, not something this tool adds or misses — if your source data might contain accidental duplicate keys, catching them requires reading the raw text yourself, since parsing alone will never surface the collision.
Reading the error message and its position
A failed validation reports "Invalid JSON: " followed by whatever message the browser's own JSON parser produced, unmodified. On current Chromium-based browsers that message names the exact character offset and, often, the line and column — for example, a trailing comma before a closing brace produces something like Expected double-quoted property name in JSON at position 16 (line 1 column 17), pointing at the character right after the comma where a real property name was expected instead. The wording itself is not something this tool controls: different browser engines phrase the same underlying error differently, so treat the position number as the reliable part and the exact phrasing as a hint rather than a fixed contract.
What Format and Minify actually change — and one reordering quirk to know about
Format re-serializes your parsed data with two-space indentation and one key per line; Minify re-serializes the same data with no whitespace at all, on a single line. Both preserve the text of every string exactly, including non-ASCII characters and emoji, which are written out as-is rather than escaped to \u sequences — only structural characters like quotes, backslashes, and control characters are escaped. One quirk worth knowing before assuming Format never reorders anything: any key that looks like a non-negative integer — "2", "10" — is moved to the front of its object in ascending numeric order, ahead of every non-numeric key in its original order. This is not a feature of this tool; it is how every JavaScript object enumerates its own keys, and Format simply serializes the object in that order.
Syntax-valid is not schema-valid — and where to go next
A green result here means exactly one thing: the text is grammatically well-formed JSON. It says nothing about whether the data matches a particular shape your code expects — a required field being absent, or a number where a string was expected, is invisible to this tool entirely, because JSON syntax has no concept of "required" or "expected type." Once your JSON parses cleanly, the Query with SQL and Generate TypeScript buttons hand the exact same text straight to the JSON SQL Analyzer or the JSON to TypeScript Generator without you needing to copy or retype anything — useful next steps for querying its actual shape or generating types and a runtime schema from it.