JSON Validator — check syntax and pinpoint errors instantly

The JSON validator above checks whether the text you paste is syntactically correct JSON — not "close enough," not "would work as a JavaScript object," but strictly valid according to the JSON specification. If it's valid, you get a clean, pretty-printed version. If it's not, you get the exact parser error and, where the browser provides it, the position it choked on.

We built this as a companion to our live JSON Formatter — Arb Digital's developers reach for a strict validator constantly when debugging API payloads and config files, and it made sense to give that same tool away for free.

What This JSON Validator Does

You paste JSON into the input box and click Validate. Behind the scenes, the tool runs it through the browser's built-in JSON parser. If parsing succeeds, it shows "Valid JSON," reformats the structure with two-space indentation, and reports how many top-level keys the object (or how many items the array) contains. If parsing fails, it shows "Invalid JSON," extracts the error message the parser produced, and — because JavaScript's JSON parser reports the character position of the failure — calculates and displays the corresponding line and column number so you can jump straight to the problem instead of scanning the whole document.

How to Use It

1. Paste your JSON — an API response, a config file, a snippet from documentation, anything.
2. Click Validate JSON. The result hero immediately shows Valid or Invalid.
3. If invalid, check the line and column. They point to the exact character where parsing failed, though note that JSON errors sometimes point slightly downstream of the real mistake (see below).
4. If valid, copy the reformatted version straight from the output box, or run it through the JSON Formatter for more formatting options.

Syntax vs. Schema: What "Valid" Actually Means Here

This tool checks syntax — is the text structured the way JSON's grammar requires — not schema, meaning it doesn't check whether the data has the specific keys, types, or shape your particular application expects. Those are two genuinely different problems. Syntax validation answers "is this parseable JSON at all?" Schema validation answers "does this parseable JSON have a name field that's a string and an age field that's a number, matching what my code expects?" You need the first before the second is even meaningful, and a lot of "my API integration is broken" bugs turn out to be a syntax problem masquerading as a schema problem — a stray trailing comma from hand-editing a config file, for instance, which this tool catches immediately. Per the official JSON specification at json.org, the grammar is intentionally small and strict, which is exactly what makes syntax checking a fast, unambiguous yes-or-no question.

Why JSON Is Stricter Than a JavaScript Object Literal

This is the single biggest source of confusion for developers new to JSON: it looks almost exactly like a JavaScript object literal, but the two have meaningfully different rules, and JSON's are much stricter. A JavaScript object literal is forgiving in ways JSON deliberately is not:

• No trailing commas. JavaScript happily accepts ["a", "b",]. JSON does not — that trailing comma after the last array or object item is a hard syntax error, and it's probably the single most common reason hand-edited JSON fails to parse.
• No comments. JavaScript (and JSON supersets like JSON5 or JSONC) allow // comment or /* comment */. Strict JSON has no comment syntax at all — if you need to document a JSON config file, that has to happen outside the file, or you need a format that explicitly extends JSON to allow it.
• No single quotes. JavaScript treats 'hello' and "hello" as identical strings. JSON requires double quotes, full stop; single-quoted strings are a syntax error.
• Keys must be double-quoted strings. In JavaScript, {name: "Ava"} is perfectly valid — the key doesn't need quotes at all. In JSON, every key must be a double-quoted string: {"name": "Ava"}. An unquoted key is invalid JSON even though it's valid JavaScript.
• No undefined, functions, or trailing semicolons. JSON has exactly six value types: object, array, string, number, boolean, and null. Nothing else is representable.

The practical upshot: if you copy an object literal out of JavaScript source code and paste it in expecting valid JSON, it will very often fail — usually on an unquoted key or a trailing comma — and this validator will tell you exactly where.

Reading the Error Message Correctly

Browser JSON parsers report where they gave up, which is not always exactly where the mistake is — it's usually right at or just after it. A missing closing brace, for example, often gets reported as "unexpected end of JSON input" with no useful position at all, because the parser ran out of text before it found what it expected; in that case, count your open braces and brackets against your closing ones. A trailing comma gets reported right at the position of the comma or the character after it, which is much more precise. When the error mentions a specific character like an unexpected , or a missing ", that's almost always the true location of the problem, not just the parser's best guess.

Common JSON Mistakes This Catches

• Trailing commas after the last item in an array or object.
• Unescaped double quotes inside a string value (a literal " inside text needs to be written as \").
• Using single quotes instead of double quotes for strings or keys.
• Unquoted or badly quoted keys copied from JavaScript source.
• Mismatched brackets — an array opened with [ but closed with }, or vice versa.
• Leading zeros in numbers like 007, which JSON's number grammar doesn't allow (write it as a string "007" instead if the leading zero matters).
• NaN, Infinity, or undefined as values — none of these are valid JSON; use null or a string representation instead.

A Worked Example: The Trailing Comma in the Sample

The sample loaded into the tool above has one deliberate mistake: "skills": ["JS", "Python",] — a comma sitting right after the last array item. Click Validate and you'll see exactly the kind of error this tool is built to catch: something like "Unexpected token ] in JSON at position N," with the line and column calculated from that position. Delete the trailing comma and the same document parses cleanly, reformats with consistent two-space indentation, and the hero flips to "Valid JSON" with a top-level key count of four.

This particular mistake is worth dwelling on because it's so common and so easy to introduce by accident. It happens constantly when someone edits a JSON config file by hand — adding a new line to an array or object and, out of habit from languages that tolerate it, leaving a comma after the item they meant to be last. It's also common when a value gets deleted during a quick edit and the trailing comma that used to separate it from the next item gets left behind. Neither mistake changes how the file "reads" to a human skimming it, which is exactly why a strict, automated check like this one is more reliable than a visual review.

Why Strictness Is a Feature, Not an Inconvenience

It can feel like JSON's rules are needlessly rigid compared to more permissive formats. But that rigidity is the entire point: a format with only one correct way to write a given piece of data is trivial to parse correctly and quickly in every programming language, which is exactly why JSON became the default interchange format for web APIs in the first place. A parser doesn't have to guess whether a trailing comma was intentional, whether a comment should be stripped before or after parsing, or whether an unquoted key is a typo or a valid identifier — every one of those ambiguities is simply not allowed to exist. That's what makes a JSON parser something you can trust in production code without writing extra defensive logic around it, and it's also what makes a dedicated validator like this one genuinely useful: it enforces the same strict rules a production parser will, before that parser ever sees the data.

Validator vs. Formatter: Which One Do You Need?

If your JSON is already valid and you just want it prettified with consistent indentation, our live JSON Formatter is the more direct tool for that job. This validator is built for the moment before that — when you're not sure the JSON is even parseable, and you need a fast, exact answer plus a pointer to what's wrong before you can move on to formatting or actually using the data.

Related Free Tools From Arb Digital

Once your JSON is valid, beautify it with the JSON Formatter, flatten it into a spreadsheet with JSON to CSV, or go the other way with CSV to JSON. Working with other formats? Check the XML Formatter and the YAML to JSON Converter. Browse everything in our free online tools hub.

Frequently Asked Questions