JSON Validator and Syntax Checker
Find out immediately whether a document is valid JSON, exactly where it breaks if it is not, and what the structure looks like once it parses.
Integration work, config deploys, data imports — a surprising number of incidents start with one stray comma. Validation answers a narrow question: will a standard parser accept this text, and if not, where does it fail. Parsing runs while you type, and a failure reports the line, the column and the content of that line, so you never have to count braces or quote characters across thousands of lines.
The check is performed by the browser built-in JSON parser, which follows the same rules as Node.js, Chrome and Safari, so what validates here behaves the same way in the runtime that will eventually consume it. The text exists only in the memory of the current page: it is not uploaded and not written to disk, and closing the tab discards it. For internal payloads or messages containing personal data there is no need to redact before pasting.
Where the boundary of valid JSON runs
Standard JSON is considerably stricter than a JavaScript object literal. Keys must be wrapped in double quotes; single quotes and backticks are rejected. String values may only use double quotes. No comma is allowed after the final member. Comments are illegal, whether written as // or /* */. undefined, NaN and Infinity are not values, hexadecimal numbers and numbers with a leading zero such as 012 are not allowed, and dates must be represented as strings. One thing is looser than people expect: any value may be the top level of a document, so a bare number, a quoted string or even null is a valid JSON text. A duplicate key is not a syntax error either — the parser simply takes the later value.
How the error position is computed
When parsing fails, the browser error message carries a character offset. The tool converts that offset into a line and column and slices out the line content, trimmed, for display in the status bar. Two caveats are worth remembering. The column is counted in characters, with no byte conversion, so on a line mixing scripts it can look different from the visual column your editor shows. And the offset points at where the parser noticed a problem, which is not necessarily where the mistake began — with a missing closing brace, the reported position is usually the end of the file rather than the object that was never closed.
What a valid document tells you
When the syntax is correct, the status bar reports the top-level type (object, array or primitive value), the maximum nesting depth, the total number of keys, the character count, the line count, and the UTF-8 byte size. The key count is recursive: keys inside nested objects are included, so it measures the scale of the whole document rather than the number of top-level fields. Maximum depth starts at the outermost container and increments per level, which is a quick way to tell whether a structure nests deeper than intended. When you are asking why parsing is slow, or whether a level went missing during a refactor, these numbers are more reliable than paging through the text by eye.
Frequently asked questions
- What does the one-click repair in the status bar do?
- It tries to turn the text into valid JSON: it removes // and /* */ comments, drops trailing commas before a closing brace or bracket, converts single-quoted strings to double quotes, adds double quotes around bare keys, and replaces undefined and NaN with null. The editor content is replaced only if the repair succeeds; when it still cannot parse, your original text is kept and the tool tells you it failed.
- Can JSON contain comments?
- Standard JSON does not allow comments — both // and /* */ cause a parse failure. Comments are legal only in extensions such as JSON5 and JSONC, which is what VS Code uses for its configuration files. Given a commented config, run the repair tool to strip the comments and then validate the result.
- Why is a duplicate key not reported as an error?
- The grammar only requires keys to be strings; it does not check for repeats, so {"a":1,"a":2} is valid text. The result is ambiguous, though, and the spec says the later member wins — which is exactly what JSON.parse does, leaving "a":2. If you want to know whether real data has this problem, inspect it in the tree view or sort keys first to make the duplicates adjacent.
- Why does the reported error point at the end of the file?
- That is the classic signature of an unclosed bracket or quote. The parser has to reach the end of input before it can conclude that a closing token never appeared, so it reports the position after the last character. When the end of the file looks perfectly fine, search backwards for the first unmatched {, [ or double quote instead of editing the last line.