JSON Validator

Paste any JSON document and see whether it parses cleanly against RFC 8259. Invalid input comes back with the exact problem, trailing comma after the last array item, unquoted key, unterminated string, single quotes where JSON demands double, bad escape sequences, plus the line and column where the parser gave up. Useful when debugging an API response, a config file, a package.json a teammate hand-edited or the output of a code generator.

How JSON validation works

  1. 1

    Paste your JSON

    Drop in a payload, a config file or an API response. Whitespace is fine; tabs and comments are not (pure JSON has no comments).

  2. 2

    Parse with a strict RFC 8259 parser

    The validator rejects anything the spec forbids: trailing commas, unquoted keys, single quotes, `undefined`, hex numbers.

  3. 3

    Read the error

    If it fails, you get the parser's message plus an approximate location: enough to navigate straight to the character.

  4. 4

    Fix and revalidate

    Correct the issue, paste again, and confirm the document is valid before committing or sending.

What strict JSON allows, and what it does not

A lot of “almost JSON” formats float around (JSON5, JSONC, HJSON, YAML-like hybrids). The JSON spec itself is small and strict; this validator tells you whether your document survives a strict parser, which is what most downstream systems actually run.

Rules that catch most people

Rule Valid Invalid
Keys must be double-quoted strings {"a": 1} {a: 1}
Strings use double quotes only "hello" 'hello'
No trailing commas [1, 2, 3] [1, 2, 3,]
No comments (none) // comment or /* */
Numbers: no leading +, no .5 0.5 +1, .5
Reserved literals only true, false, null undefined, NaN
UTF-8 encoding Unicode strings Invalid byte sequences

Common errors and what they mean

  • “Unexpected token }, you have a trailing comma before the closing brace.
  • “Expected property name”, key is unquoted or you forgot the quotes around the opening key.
  • “Unexpected end of input”, an opening { or [ is not closed; count braces.
  • “Bad control character”, a tab, newline or other control byte inside a string literal. Escape them as \t, \n, etc.
  • “Duplicate key”, not actually a JSON-spec error (the spec says SHOULD be unique), but many validators warn. The validator flags it as a notice, not a hard failure.

If you need laxer formats

  • JSON5 allows trailing commas, comments and single quotes. Use a JSON5 parser if that is your target format.
  • JSONC (JSON with comments) is what VS Code settings use. Strip comments before strict parsing.
  • YAML is a different format; do not assume it is “just indented JSON”.

Tips

  • Validate before committing. A typo in a package.json or a CI config breaks the whole build until someone notices.
  • Pretty-print after validating to make review diffs readable. A one-line JSON file is valid but miserable to review.
  • For large payloads, stream-validate (jq on the command line, for example). In-browser parsing struggles past a few MB.

Frequently Asked Questions

This tool checks syntactic validity only, is it well-formed JSON? For structural rules (required fields, enum values, string lengths), use a JSON Schema validator. The two steps are complementary: no point running Schema validation on a document that is not valid JSON in the first place.

Because standard JSON has no comments. // and /* */ are a common-sense extension (JSONC, JSON5) but pure JSON rejects them. Strip comments before sending to a strict consumer, or adopt JSON5 across your stack.

Invalid in strict JSON. The spec allows only finite numbers. Serialize them as strings ("NaN", "Infinity") or as null, depending on how your consumer handles missing data.

No, validation runs in your browser, so the payload you paste never leaves the page. Safe for sensitive config files and API responses with credentials.

Related Tools

Tool available in other languages