Skip to content
FlipConverto home

JSON Validator

A JSON validator, or JSON checker: check whether JSON parses, and get the exact line, column and cause of any syntax error.

Loading JSON Validator…

Runs entirely in your browser. What you enter stays on your device — nothing is sent to a server. Verify it yourself

What makes JSON invalid?

Trailing commas, single quotes, unquoted keys, comments, and the values NaN, Infinity and undefined. Note that a bare value is valid: 42, "hello" and null are each a complete JSON document, so "it parsed" does not mean you got an object.

Cost
Free, no limits
Upload
None — runs on your device
Sign-up
Not required
Works offline
Yes, once loaded

How to validate JSON

  1. Paste your JSON

    Into JSON to validate. It is checked as you type.

  2. Read the verdict

    Valid JSON is confirmed; otherwise you get the line and column of the first error, with that line shown.

  3. Fix and check again

    Correct the line shown — often a trailing comma, a single quote or a missing bracket — and the verdict updates.

Examples

  • JSON with a trailing commaThe exact position and an explanation

    Valid JavaScript, invalid JSON — the most frequent cause of rejection.

  • A correct documentConfirmation that it parses

    Useful before committing generated output.

Key features of the JSON Validator

  • Reports the line and column of a syntax error
  • Explains what was expected at the failure point
  • Confirms validity for well-formed input
  • Never leaves your browser

What it checks

Accepts

  • Standard JSON (RFC 8259)

Reports

  • Line
  • Column
  • The line with the error

Rejected, as JSON requires

  • Comments
  • Trailing commas
  • Single quotes

When should you use this?

  • Finding why a config file was rejected by a build tool.
  • Checking generated JSON before it is deployed.
  • Locating a syntax error in a large document quickly.

Limitations

  • This validates syntax, not structure. A document can be perfectly valid JSON and still be wrong for its purpose — missing required fields, wrong types, values out of range. Checking that needs a schema, which this does not do.
  • Only the first syntax error is reported. Fixing it may reveal another.
  • Duplicate keys are not flagged. The specification permits them and most parsers silently keep the last, which is a genuine source of bugs this tool will not catch.

Troubleshooting

The reported position looks wrong

A parser reports where it noticed the problem, not where the mistake was made. An unclosed brace is only detectable at the end of the input.

It validates here but is rejected elsewhere

The other tool probably wants a specific structure, or uses a stricter dialect. Valid JSON is a low bar that says nothing about whether the content is what a consumer expects.

Common mistakes to avoid

  • Assuming valid means correct. Syntax and semantics are different questions.
  • Ignoring duplicate keys because nothing complained. The last one silently wins.

Pro tips

Tips for better results

  • Debugging

    Fix errors top-down: the message is often below the real fault

    Work top-down when fixing errors. A single missing bracket often produces a confusing message far below its real location.

  • Beyond syntax

    JSON Schema is the other half of validation

    If you need structural validation, JSON Schema is the standard — this tool is the syntax half of that job.

Standards and terms behind the JSON Validator

The named things this tool works with, and the documents that define them.

JSON (RFC 8259)Specification
The data interchange format of the web: objects, arrays, strings and numbers. Reference: JSON (RFC 8259)
IETFWho made it
The body that publishes RFCs, including those defining WebP, FLAC, Opus, Matroska and JSON.
Character encodingHow it works
The mapping from bytes to letters; the wrong one turns accents and emoji into rubbish.

Also searched as: is my json valid, find the json syntax error, json lint.

Valid is not the same as correct

A document that parses is syntactically valid JSON. That says nothing about whether it has the fields your API expects, the right types, or sensible values. The summary above reports the shape it found — root type, number of values, key count, nesting depth — because "it parsed" on its own rarely answers the question you actually had.

Nesting depth

Depth is worth watching. Many parsers and API gateways impose a maximum nesting depth as a defence against stack-exhaustion attacks, and those limits are often lower than people expect — some as low as 20 levels. A document that parses fine in a browser can be rejected downstream for depth alone.

Common validity traps

A bare value is valid JSON: 42, "hello" and null are all complete, valid documents. If your consumer expects an object, "valid JSON" is not sufficient.

Duplicate keys are not a parse error either. The specification leaves the behaviour undefined, and most parsers silently keep the last occurrence — which means a document with a duplicate key can parse differently in two languages.

Privacy

The JSON Validator runs entirely in your browser. What you enter and the result it produces stay on your own device — nothing is sent anywhere, because nothing needs to be.

You can confirm this rather than take our word for it: open your browser’s developer tools, watch the Network tab, and use the tool. No request carries your input. It also keeps working with the connection off.

Details are in the privacy policy.

What next?

Once it parses, indentation makes the structure visible.

Format it for reading

JSON Validator — questions

What makes JSON invalid?

Trailing commas, single quotes, unquoted keys, comments, and the values NaN, Infinity and undefined. Missing commas between items and unclosed brackets or braces are the other common causes.

Is a single number valid JSON?

Yes. Since JSON was standardised as RFC 8259, any value — a number, a string, true, false or null — is a complete JSON document. If your consumer needs an object, check the root type as well as validity.

What happens with duplicate keys?

The specification leaves it undefined. Most parsers keep the last occurrence, but not all, so a document with duplicate keys can parse to different results in different languages. Avoid them.

Why does the validator report nesting depth?

Because many parsers and API gateways cap it, often lower than people expect, as protection against stack exhaustion. A deeply nested document can validate here and be rejected downstream.

Part of Developer Tools · Browse every tool