Online JSON Validator

What a JSON validator actually checks

To validate JSON means one narrow thing: asking whether the text conforms to the grammar in RFC 8259. That grammar is tiny — six value types, strings in double quotes, commas between elements and nothing after the last one. A JSON syntax checker stops at the first character that cannot legally appear where it appears; reach the end without stopping and your JSON is valid.

Two very different questions both get called validation, and only the first is answered here.

So a document can pass here and still be useless to your code: {"age": "forty-two"} is flawless JSON and completely wrong if your API expects a number. Check syntax first, shape second — a schema validator has to parse before it can inspect.

Because indenting requires parsing, the JSON formatter validates too: if it refuses to produce output, the input is not valid JSON.

How to validate JSON

1. Paste the JSONOpen the JSON viewer and paste your payload into the input panel, or drop a .json file onto the page. Parsing runs locally, so nothing is uploaded.
2. Read the status pillThe pill above the editor reads Valid JSON or Invalid JSON. Validation is continuous, so it updates on every keystroke and there is no button to press.
3. Jump to the line and columnWhen the document is invalid the error card names the reason and gives the exact line and column, with a caret under the offending character.
4. Fix it and re-checkEdit in place and watch the pill. A parser stops at the first problem, so a badly broken file takes a few rounds to turn green.

One error at a time is by design: past an illegal character a parser no longer knows what you intended. The cursor readout also shows Ln and Col for steering through a long file.

Every common JSON error, decoded

Almost every JSON error has one root cause: JSON looks like a JavaScript object literal but is far stricter. Engines word the same failure differently, so match the shape of a message, not the letter.

Trailing commas

The most common JSON error by a wide margin, and the nastiest: the offending comma sits on a line you did not touch — you deleted the entry after it.

{
  "items": [1, 2, 3,],
  "total": 3,
}

{
  "items": [1, 2, 3],
  "total": 3
}

Note where the parser points: not at the comma but at the } or ] that followed it. Always look one token left of the reported position.

Single quotes and unquoted keys

JSON has exactly one string delimiter, the double quote, and it applies to keys as well as values.

{
  name: 'Ada',
  'role': "engineer"
}

{
  "name": "Ada",
  "role": "engineer"
}

Python is the other frequent source: printing a dict gives {'name': 'Ada'} with single quotes and True, False and None capitalised — none of it JSON. Use json.dumps(), not print().

Comments

There is no comment syntax in the JSON grammar; it was left out so nobody could smuggle parsing directives into a data format.

{
  // the port the server listens on
  "port": 8080,  /* default */
  "debug": false
}

{
  "_comment": "port the server listens on",
  "port": 8080,
  "debug": false
}

tsconfig.json and VS Code's settings.json do accept comments — those are read as JSONC, a superset. Send the same file to an API expecting JSON and it is rejected.

Unescaped characters inside strings

Two rules govern the inside of a JSON string, and this example breaks both. A backslash always begins an escape sequence, and only nine are legal: \" \\ \/ \b \f \n \r \t and \uXXXX. And every character below U+0020 — a line break, a spreadsheet tab — must be escaped.

{
  "path": "C:\Users\ada\data.json",
  "note": "first line
second line"
}

{
  "path": "C:\\Users\\ada\\data.json",
  "note": "first line\nsecond line"
}

\U is not one of the nine, so the parser stops on the first backslash of the Windows path. The lesson: never build JSON by concatenating strings — let a real serialiser do the escaping.

Valid, but not what you expected

A green pill answers exactly one question. Everything below is well-formed JSON that any validator will pass, and each has cost somebody an afternoon.

• Duplicate keys do not raise an error. RFC 8259 says names within an object should be unique — a recommendation, not a requirement. JSON.parse silently keeps the last, so {"id": 1, "id": 2} becomes {"id": 2}. Other implementations keep the first, so two services can disagree about one file while both call it valid.
• Large integers quietly lose precision. JSON numbers have no size limit, but most parsers hand you an IEEE 754 double, exact only to 2⁵³ − 1. A 64-bit database ID past that point comes back rounded:

  JSON.parse('{"id": 9007199254740993}').id
  // → 9007199254740992   off by one, silently

  Send such identifiers as strings.
• null is not the same as a missing key. {"middleName": null} asserts there is no middle name; {} says nobody asked. A check like if (!user.middleName) flattens a distinction the data was careful to make — use "middleName" in user instead.
• A bare value is a complete JSON document. Since RFC 8259 replaced RFC 4627, any value may sit at the top level: 42, "text", true and null are each a valid JSON text. A parser that insists on an object or array is out of date.
• An empty string is not valid JSON. A zero-length file, or a response body with nothing in it, contains no value at all; whitespace alone fails the same way. If nothing must be representable, write null or {}. This tool shows an Empty state for a blank editor, but an empty API response is a real bug.

None of these is catchable by a syntax checker — the honest limit of what any JSON linter can promise. Past parsing, the rest belongs to your schema, tests and types.

Frequently asked questions

Related tools