JSON Validator

What "valid JSON" means

Valid JSON is text that a strict parser accepts under RFC 8259: double-quoted keys and strings, no trailing commas, no comments, numbers in plain decimal notation (no NaN, Infinity, hex or leading zeros), only true, false and null as literals, and nothing after the top-level value except whitespace. Any single value is a valid document, so 42 and "ok" pass too.

This validator checks exactly that and nothing more. Because it uses the browser's parser, the error you see here is the one your front-end code will throw. In Chrome and Edge it is the same text Node.js prints; Firefox and Safari word it differently.

JSON error messages by runtime

The same mistake produces different messages in each runtime, which makes them hard to search for. V8 (Chrome, Edge, Node.js) gives a 0-based character position; Firefox and Python give a 1-based line and column. Recent V8 versions append (line L column C) as well, and older V8 (Node.js 18 and earlier) used the form Unexpected token } in JSON at position 7. Python's "Illegal trailing comma" wording is new in 3.13; earlier versions report a trailing comma as Expecting property name enclosed in double quotes or Expecting value.

{"a":1,}

{'a':1}

{"a":1 // note
}

{"a":NaN}

{"a":1

{"a":"line1
line2"}

\uFEFF{"a":1}  (invisible first character)

<!DOCTYPE html>...

{"a":1}{"b":2}

(empty string)

To find a V8 position in a large file, paste it here and use the editor's line numbers, or run text.slice(pos - 20, pos + 20) on the string to see the surrounding characters. When there are many errors at once, the JSON repair tool fixes quotes, commas and comments in one pass, and how to fix broken JSON walks through each fix by hand.

Valid JSON that still causes bugs

Passing validation only means the text parses. These inputs are valid, so no validator flags them, but they change your data silently:

Duplicate keys

JSON.parse('{"role":"user","role":"admin"}')
// { role: "admin" }  (last one wins, no error)

RFC 8259 only says keys "SHOULD" be unique. JavaScript, Python and jq keep the last value; some other parsers keep the first or reject the document. That disagreement has been used to slip a different value past a validating service. JSON.parse cannot detect duplicates, so neither can this page; in Python you can:

import json

def reject_duplicates(pairs):
    keys = [k for k, _ in pairs]
    dupes = sorted({k for k in keys if keys.count(k) > 1})
    if dupes:
        raise ValueError(f"duplicate keys: {dupes}")
    return dict(pairs)

json.loads('{"role":"user","role":"admin"}', object_pairs_hook=reject_duplicates)
# ValueError: duplicate keys: ['role']

Large integers lose precision

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

JSON.parse('1e400')
// Infinity

JavaScript numbers are 64-bit floats, exact only up to Number.MAX_SAFE_INTEGER (9,007,199,254,740,991). 64-bit database IDs and snowflake IDs above that are rounded silently. The usual fix is to send them as strings. Python's json keeps integers exact, so the same payload can give different IDs in a Python backend and a JavaScript front end. Chrome 114+ and Node.js 21+ pass the original source text to a reviver ((key, value, context) => context.source), which lets you convert such fields to BigInt.

Encoding problems

RFC 8259 requires UTF-8 for JSON exchanged between systems. A file saved as Latin-1 or UTF-16 may parse but turn é into é. Lone surrogate escapes such as "\uD800" parse in JavaScript and Python but fail later when the string is encoded to UTF-8.

Validate JSON from the command line or CI

Each of these exits with a non-zero status on invalid input, so they work in scripts and pre-commit hooks:

# Python (no install); prints the error with line and column
python3 -m json.tool data.json > /dev/null

# jq; "empty" parses the input and prints nothing if it is valid
jq empty data.json

# Node.js; same parser and messages as Chrome
node -e 'JSON.parse(require("fs").readFileSync(process.argv[1], "utf8"))' data.json

Note that readFileSync(..., "utf8") keeps a BOM, so a file saved with one fails in Node.js even when it opens fine in an editor.

Syntax vs schema

Syntax validation answers "can this be parsed?". Schema validation answers "is this the data my code expects?": required fields, types, formats and ranges. This tool does only the first. For the second, describe the shape in JSON Schema and check it in your code or CI, for example with Ajv:

import Ajv from "ajv";

const validate = new Ajv().compile({
  type: "object",
  required: ["id", "email"],
  properties: { id: { type: "integer" }, email: { type: "string" } },
});

validate({ id: "42" });          // false
console.log(validate.errors);    // [{ instancePath: "", message: "must have required property 'email'" ... }]

Ajv stops at the first error unless you pass { allErrors: true }, which is why only the missing email is reported above and not the string id.