Visual Studio Code validates JSON files automatically when they have a .json extension, surfacing syntax errors as red squiggles and Problems panel entries with the line and column where parsing failed. This built-in behavior comes from VS Code's bundled JSON language service, which understands the same grammar that JavaScript runtimes enforce, so most simple mistakes show up the moment you save. The catch is that VS Code's error messages are short, sometimes cryptic, and tied to where you happen to be looking in the file. When you are debugging a 500-line API response or a deeply nested config, a vague "Unexpected token" is not enough — you want the precise line, the precise column, and a clear statement of what the parser actually expected. That is exactly what a dedicated JSON Validator gives you, running in your browser with no extension to install and no project to open.
Why VS Code's Built-In JSON Validation Sometimes Falls Short
VS Code ships with a JSON language service that activates the moment you open a file with a .json extension. As you type, the parser checks your work against the standard grammar and underlines problems in real time. For small, hand-written files like package.json or settings.json, this is genuinely useful — you save and the editor has already caught a trailing comma or a missing brace.
But the built-in validator has limits that show up the moment your JSON stops being small or friendly:
- Error messages are abbreviated. "Unexpected token" tells you almost nothing about which character or which structure the parser objected to.
- No structural overview. VS Code tells you JSON is broken, not how deep it nests or how many keys it contains. When a payload looks suspicious but parses cleanly, you have no quick way to spot accidental depth or unexpected shape.
- File detection can fail. If VS Code does not detect a file as JSON (no .json extension, wrong file association, mixed content), the validator never runs at all.
- Some valid JavaScript is invalid JSON. Comments, trailing commas, and single quotes are legal in JavaScript object literals — paste a snippet from a tutorial into VS Code and the editor may flag syntax that looks perfectly fine to you.
For these situations, a focused validator gives you a second opinion that is built around exactly one question: is this JSON well-formed, and if not, where does it break?
Common JSON Syntax Errors That Trip Up VS Code Users
Standard JSON is governed by RFC 8259, and it is strict in ways that surprise developers every day. The most common reasons a JSON file fails validation in VS Code — or anywhere else — are:
- Unquoted or single-quoted object keys. { name: "Ada" } looks reasonable; it is illegal. Keys must be double-quoted strings: {"name": "Ada"}.
- Single quotes for string values. 'hello' is fine in JavaScript and Python but not in JSON. Use "hello".
- Trailing commas. {"a": 1, "b": 2,} is rejected. The comma after the last element has no place in the grammar.
- Comments. // line comment and /* block comment */ are not part of JSON, even though most editors tolerate them in JavaScript. JSON5 and JSONC exist as separate formats; vanilla JSON does not allow comments.
- NaN, Infinity, and undefined. These are JavaScript conveniences, not JSON values. A number must be a finite decimal representation.
- Unbalanced brackets or braces. One missing ] or } somewhere in a 400-line file produces a confusing error far from the actual typo.
| Mistake | Looks like | Why it fails |
|---|---|---|
| Single-quoted string | 'name': 'Ada' | RFC 8259 requires double quotes for both keys and string values |
| Trailing comma | {"a":1,} | Comma must separate items; no comma after the last element |
| Comment in JSON | // note | Comments are not defined in the JSON grammar |
| Unquoted key | {name: "Ada"} | All keys must be quoted strings |
| NaN value | {"x": NaN} | NaN is not a valid JSON number |
Every one of these produces a different parser error, and VS Code's short message rarely names the rule that was violated. A validator that surfaces the parser's full message alongside the line and column lets you jump straight to the problem instead of scanning the file by eye.
Validate JSON with the JSON Validator Tool
When you need an unambiguous answer about whether a chunk of JSON is well-formed — without installing an extension or opening a project — the JSON Validator tool runs the parser your browser already uses and reports the result in plain language. Here is the exact workflow:
- Paste or type your JSON into the input box. Copy the file contents from VS Code and drop them into the validator, or type directly. The input accepts any size that fits in the box.
- Read the verdict instantly. A green indicator confirms valid JSON. If parsing fails, a red error appears with the parser's own message and, wherever the engine supplies one, the precise line and column where parsing broke — for example, "Invalid JSON at line 3, column 7." Different browsers word this slightly differently (V8 in Chrome and Edge, SpiderMonkey in Firefox, JavaScriptCore in Safari), and the tool normalizes the position from whichever engine reported it.
- Review the structure report for valid JSON. Once the parser is happy, the validator stops being a red-light/green-light test and starts being a diagnostic. It reports the top-level type (object, array, string, number, boolean, or null), the maximum nesting depth, the total number of keys across all levels, the count of objects and arrays, and the character count.
That third step is the part VS Code never does. After fixing a syntax error, you can confirm the result is structurally what you expected — a flat config with three keys, a deeply nested response that should have been flat, or a list that quietly grew from 50 items to 500.
Reading the Structure Report
The structure report exists because valid JSON can still be wrong JSON. An API might return a 200 status with a payload whose shape does not match your TypeScript types. A config file might parse cleanly but accidentally nest arrays inside arrays inside arrays. The report answers four practical questions:
- What is the top-level type? An object, an array, a primitive — useful when you expected one and got another.
- How deep does it nest? Excess depth is a smell. If your schema expects two levels and you see ten, something has gone wrong upstream.
- How many keys does it contain, in total? A response with 4,000 keys is probably not what your code is built to handle. The key count is a rough payload size signal.
- How many objects and arrays are inside? Helps you spot duplicates, oversized sections, or stripped wrappers.
The validator deliberately leaves your text unchanged so you can fix syntax without accidentally editing formatting. If you also want to pretty-print or minify the same data, that is a separate job — the validator focuses purely on correctness checking, error localization, and structural diagnostics.
JSON Validator vs JSON Formatter
These two tools answer different questions, and knowing which one you need saves time.
| Feature | JSON Validator | JSON Formatter |
|---|---|---|
| Checks syntax against RFC 8259 | Yes | Yes |
| Reports line and column of errors | Yes | Yes |
| Pretty-prints JSON | No | Yes |
| Minifies JSON | No | Yes |
| Reports structural stats (depth, key count) | Yes | No |
| Reformats input | No | Yes |
If you are debugging "why does this fail to parse," use the validator. If you are cleaning up indentation or stripping whitespace for a network payload, use a formatter. The validator is the right home when you specifically do not want your text touched.
Privacy, Precision, and the RFC 8259 Standard
Validation in the JSON Validator runs entirely on your browser's native parser, which implements the grammar defined in RFC 8259 — the same standard JavaScript runtimes, Node.js, and most production JSON libraries follow. There is no lenient guessing, no auto-repair, and no server upload: your JSON never leaves the page, which matters when you are checking tokens, credentials, or private API responses.
One caveat is worth knowing. JSON numbers are read as IEEE-754 doubles, so integers larger than 2^53 lose precision when parsed. A green "Valid JSON" verdict confirms your data is syntactically correct, not that a 64-bit identifier survived intact. If your payload uses big integers (database IDs, Snowflake IDs, OAuth nonce values), treat validator output as a syntax check and verify numeric integrity with a separate tool.
Deeply nested input is handled safely too: even pathological structures that would crash a naive recursive walker are caught by the engine's parser and reported as errors instead of freezing your tab. That makes the validator suitable for unusual inputs — fragments pasted from REST clients, malformed webhook payloads, truncated logs — where you genuinely do not know what you are about to feed in.
For a deeper look, see JavaScript Key Code Finder: Decoding KeyboardEvent Fields.
For a deeper look, see JSON to XML Alternative Built on a Typed Mapping.