JSON Validator

Saying something useful when nothing is wrong

A formatter's job ends when the document is reformatted. A validator's job is to deliver a verdict, and "valid" on its own is the least informative true thing a tool can say. So this page reports the shape:

Valid JSON · object · 5 keys · depth 3 · 412 values

Four facts, each of which catches a different mistake. The type catches the case where you expected an array of records and have a single object, which is the most common reason an import produces one row instead of a thousand. The key count catches a truncated paste. The depth tells you what you are in for when the next step is flattening. The value count is the number of scalars in the whole document, which is the closest thing to a size that means anything.

Depth is counted the way you would count it by eye: a scalar is depth 0, a flat object is depth 1, and an object holding an object holding an array of numbers is depth 3.

What the tolerant reader forgives

Half of what people paste into a JSON validator is not strict JSON and was never going to be: a config file with comments in it, a dictionary copied out of a Python shell, an object lifted from a JavaScript source with unquoted keys, a snippet that went through a word processor and came back with curly quotes.

Leave Forgive comments, trailing commas and quotes on and all of those are read, and the note above the result says exactly what had to be forgiven. That is the important half: a person who does not know their file used single quotes learns nothing from a tool that silently accepts it, and will paste the same thing into the next one.

{
  // a config file, not strict JSON
  'service': 'billing',
  replicas: 3,
  enabled: True,
  limits: { cpu: '500m', memory: '512Mi', },
}

reads as valid, with the note:

Read as relaxed JSON (fixed: comments, single-quoted strings,
unquoted keys, Python True/False/None, trailing commas). A strict
JSON parser would refuse the input as it stands.

Turn the option off and the same document is a syntax error with a caret under the first comment. Which of those two behaviors you want depends on whether you are checking a config file or checking an API payload, and that is exactly the choice the toggle offers.

JSON Lines, and other things that are nearly JSON

• JSON Lines (one value per line, no surrounding array) is recognized. A whole-document parse fails on it, so the validator retries line by line and, when most lines parse, reports the error against the line number rather than against a character offset in a document the file was never meant to be.
• A byte order mark at the start, which Windows tools add and which makes the first character of the document invisible-but-present, is stripped before parsing. Left in place it produces an "unexpected token" at position 0 that looks impossible.
• A truncated paste produces "unexpected end of input", located at the end of the document rather than nowhere, which is what the raw message gives you.
• A schema that is itself broken is reported separately, with its own line and column, so you are never told your document is invalid when the problem is in the rules.

When you want the document reformatted rather than judged, the JSON formatter is the page for that, and it shares this error reporting.