How to Validate JSON

JSON looks simple enough that many people assume it's hard to get wrong, a few braces, some quotes, done. In practice, hand-written or hand-edited JSON breaks constantly, usually from one of a handful of predictable mistakes. Validating JSON is the process of checking whether a piece of text conforms to the JSON specification, and doing it well means understanding both what the spec actually requires and how to read the error messages a validator gives you.

What Makes JSON Valid

The JSON specification (formally, RFC 8259) is deliberately small. A valid JSON document is one of: an object, an array, a string, a number, true, false, or null. From there, the rules are strict:

• Objects are wrapped in {} and contain zero or more "key": value pairs, separated by commas. Keys must be double-quoted strings.
• Arrays are wrapped in [] and contain zero or more comma-separated values of any type.
• Strings must use double quotes, not single quotes. Certain characters (like literal double quotes or backslashes inside a string) must be escaped with a backslash.
• Numbers don't support leading zeros, trailing decimal points, or values like Infinity and NaN, those are JavaScript concepts, not JSON ones.
• No trailing commas. Unlike JavaScript object and array literals, JSON does not permit a comma after the last element.
• No comments. There is no comment syntax anywhere in the JSON specification.

Because the spec is strict and mostly unambiguous, a validator can give you a definitive yes-or-no answer, unlike more flexible formats where "valid" can be a matter of interpretation.

Why a Separate Validator Is Useful

You might wonder why validation deserves its own tool rather than just trying to format the JSON and seeing whether it errors out. In practice, both approaches use the same underlying check (JSON.parse succeeding or failing), but a dedicated validator is optimized for a different workflow: you're not trying to produce clean output, you're trying to confirm correctness as quickly as possible, often while actively editing.

A good JSON validator gives you three things a plain parse error doesn't always make obvious:

1. A clear valid/invalid signal, so you don't have to interpret ambiguous output.
2. Line and column information, so you can jump directly to the problem instead of scanning the whole document.
3. A plain-language explanation, translating something like "Unexpected token } in JSON at position 42" into "there's likely a missing comma or an extra closing brace near this point."

Reading Validator Error Messages

JSON parsers report the character position where parsing failed, which validators convert into a line and column number for readability. It's worth understanding what that position actually means: it's where the parser first noticed something was wrong, which is not always where the actual mistake is.

For example, a missing comma between two object properties will often be reported at the start of the next property, not at the end of the property that's missing its comma, because the parser doesn't know a comma is missing until it starts trying to parse what comes next and finds a key where it expected a comma or closing brace. When an error location doesn't obviously point at a mistake, check the token immediately before the reported position, not just the position itself.

A Debugging Checklist

When a validator reports invalid JSON, work through this checklist in order:

1. Check for a missing comma immediately before the reported line and column.
2. Check for a trailing comma right before a closing } or ].
3. Check quote characters. Every key and every string value must use double quotes, a stray single quote or "smart quote" (curly quote) pasted from a word processor is a very common source of errors.
4. Check bracket balance. Count opening and closing braces and brackets; an extra or missing one anywhere in a large document can be hard to spot visually but will always break parsing.
5. Check for comments. If the source was hand-edited config with // or /* */ comments, those need to be removed, JSON has no comment syntax.
6. Check for non-JSON values. undefined, function references, and JavaScript-specific values like NaN are valid in JavaScript object literals but not in JSON.

Validating JSON From Different Sources

Where the "broken" JSON came from often tells you what kind of mistake to expect:

• Hand-written JSON (like a manually edited config file) most often has trailing commas, single quotes, or unquoted keys, since these are all valid in the JavaScript syntax people are used to typing.
• Copy-pasted JSON from documentation or a chat tool frequently picks up "smart quotes" from rich-text editors, which look like regular quotes but are different Unicode characters and will break parsing.
• Programmatically generated JSON that fails to validate is usually a sign of a bug in whatever generated it, for example, string concatenation that didn't escape a value correctly, producing an unescaped quote inside a string.
• Truncated JSON (cut off partway through, often from a copy-paste that missed the end of a long response) will typically report an "unexpected end of input" error, since the parser runs out of text before it finds matching closing brackets.

Validation Is Not the Same as Schema Checking

It's worth being clear about scope: JSON validation, in the sense discussed here, only confirms that text is syntactically well-formed JSON. It does not check whether the data has the fields you expect, whether values are the right type for your application, or whether required fields are present. That's a different, more application-specific problem usually solved with a schema validation library (like Zod or JSON Schema) rather than a general-purpose JSON validator. Syntax validation is the first, necessary step, but passing it only means the JSON can be parsed, not that it means what you expect.

Try It Yourself

Our JSON Validator runs entirely in your browser and gives you instant feedback with line and column information as you type or paste. Because nothing is uploaded anywhere, it's safe to use even with JSON that contains sensitive data. Once your JSON validates successfully, you can move on to our JSON Formatter to make it readable, or the JSON Minifier if you need to shrink it for transport.