JSON Validator

About JSON Validator

How to use the JSON Validator

1. Paste the document you want checked.
2. Read the result: valid, or the position and reason it is not.
3. Fix the reported problem and re-check - a document often has more than one issue, and parsers report only the first.
4. If it is syntactically valid but your API still rejects it, you need schema validation rather than syntax validation.

Examples

• Valid document

  {"status":"ok"}

  Copy example

JSON Validator in code

The same operation this tool performs, in the languages you are most likely to need it.

# jq: exits non-zero and prints the error, no output on success
jq empty file.json

# Every JSON file in the repo
find . -name '*.json' -not -path './node_modules/*' \
  -exec sh -c 'jq empty "$1" || echo "INVALID: $1"' _ {} \;

# Without jq
python3 -c "import json,sys; json.load(open(sys.argv[1]))" file.json

function validateJson(raw) {
  try {
    JSON.parse(raw);
    return { valid: true };
  } catch (e) {
    // V8 includes the character offset in the message
    const at = /position (\d+)/.exec(e.message)?.[1];
    const line = at ? raw.slice(0, +at).split("\n").length : undefined;
    return { valid: false, message: e.message, line };
  }
}

// Guard against the HTML-instead-of-JSON case before parsing at all
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
if (!res.headers.get("content-type")?.includes("json")) {
  throw new Error(`Expected JSON, got ${res.headers.get("content-type")}`);
}

import json

def validate(raw: str):
    try:
        json.loads(raw)
        return True, None
    except json.JSONDecodeError as e:
        return False, f"{e.msg} at line {e.lineno}, column {e.colno}"

# Reject pathological documents rather than merely invalid ones:
# cap the body size before parsing, and check nesting depth after.
if len(raw) > 5_000_000:
    raise ValueError("payload too large")

When you need this

• Checking a config file parses before deploying it.
• Triaging why an API returned 400 on a body you believe is correct.
• Validating every JSON file in a repository as a CI step.
• Confirming a document survived a copy-paste out of a log or a terminal intact.
• Establishing whether a problem is syntax or schema before you go looking further.

Common problems and what causes them

"Unexpected token < in JSON at position 0"

The response was HTML, not JSON - almost always an error page, a login redirect, or a proxy notice. Your code called response.json() on a 404 or 500 body. Check the status code and the content-type header before parsing.

"Unexpected end of JSON input"

The document is truncated: a stream cut short, a response body read twice, a log line clipped at a column limit, or a file that never finished writing. Count your closing braces and brackets - the tool points at where the structure stops making sense.

"Expected property name or '}' in JSON at position N"

Usually a trailing comma before a closing brace or bracket, which JavaScript object literals allow and JSON does not. It can also be an unquoted key: JSON requires double quotes around every property name.

Single quotes instead of double quotes

JSON only accepts double quotes, for both keys and string values. Single-quoted output is a sign the data came from a Python repr, a JavaScript object literal, or a log statement rather than a real JSON serialiser.

NaN, Infinity, or undefined in the document

None of these are valid JSON. They appear when a serialiser wrote out floating-point specials or a JavaScript undefined. Emit null instead, or a string if the distinction matters.

A byte-order mark at the start of the file

A UTF-8 BOM (EF BB BF) before the opening brace makes strict parsers report an unexpected character at position 0, even though the file looks perfect in an editor. Save as UTF-8 without BOM.

Comments in a JSON file

// and /* */ are not part of JSON, however common they are in config files. Tools that accept them are parsing JSON5 or JSONC. Strip comments before feeding the document to a strict parser.

Large integers losing precision

JSON numbers become IEEE-754 doubles in most parsers, so integers above 2^53 - Twitter-style snowflake ids, for instance - silently lose their last digits. Serialise those as strings, or use a parser with bigint support.

FAQ

What is the difference between JSON validation and JSON Schema validation?

This page checks syntax - whether a parser can read the document at all. JSON Schema validation checks structure and types: that required fields are present, that a value is a string rather than a number, that an enum only contains allowed values. A document can pass the first and fail the second.

Where exactly is my error?

The reported position is a character offset from the start of the document, which usually lands on or just after the offending token. Note that parsers stop at the first error, so fixing one can reveal another.

Is an empty document valid JSON?

An empty string is not. The smallest valid documents are {} and [], and per the current specification a bare value like 42, "text", true or null is also a valid JSON document.

Are duplicate keys valid?

The specification does not forbid them, but the behaviour is unspecified and parsers differ - most keep the last occurrence. Treat duplicates as a bug in whatever produced the document, because two systems may disagree about what it means.

Does valid JSON mean it is safe to parse?

No. A valid document can be enormous or nested thousands of levels deep, either of which can exhaust memory or stack. Servers should limit body size and nesting depth independently of validity.

Does it validate JSON Schema?

This tool checks syntax only, not JSON Schema or OpenAPI rules.

Related reading

• How to pretty-print JSON
• Common JSON validation errors
• JSON Schema validator check structure too
• JSON formatter format and fix