This tool checks whether a string is valid JSON in your browser; nothing leaves your machine. “Valid JSON” here means syntactically valid — does it parse — not “matches an expected structure.” For schema validation, see the JSON Schema discussion below.

What syntactic validation checks

A JSON parser walks the input and confirms the structure follows RFC 8259:

Top-level value must be an object, array, string, number, boolean, or null.
Object keys must be strings (always quoted).
All strings must use double quotes.
No trailing commas after the last element of an array or object.
No comments.
Numbers must be in standard form (no leading zeros except 0 itself, no trailing decimal point, etc.).

The tool above runs the input through JSON.parse() and reports either “valid” or the parse error and its position.

Common parse errors

Error	What it means
`Unexpected token } in JSON at position N`	A trailing comma or extra `}`.
`Unexpected end of JSON input`	The input was truncated; missing closing brace, bracket, or quote.
`Unexpected token '`	Single quotes are not valid JSON; use double.
`Unexpected token /`	Comments aren’t valid JSON.
`Unexpected number in JSON`	A number with leading zero, trailing decimal, or other malformed form.
`Unexpected token N in JSON at position 0`	The first character isn’t a valid JSON token; possible BOM bytes.

The tool above shows the position of the first error so you can find it quickly.

What syntactic validation doesn’t check

Whether the structure matches what your code expects. {"naame": "Alice"} (typo in the key) parses fine but probably isn’t what you wanted.
Whether values fall in expected ranges. {"age": -5} is valid JSON; semantically wrong.
Whether required keys are present. {} is valid JSON; your code may need name and email.
Whether the encoding is right. A Latin-1 file misparsed as UTF-8 may produce mojibake but still parse as valid JSON if no high-bit bytes corrupt structure characters.
Whether the bytes are duplicate-key-free. {"a": 1, "a": 2} is technically valid in some interpretations and undefined in others. Most parsers silently keep the last value.

Schema validation

For the layer above syntactic validation: JSON Schema. A JSON Schema describes what shape a JSON document must have:

{
  "type": "object",
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age":  { "type": "integer", "minimum": 0, "maximum": 150 },
    "email": { "type": "string", "format": "email" }
  },
  "required": ["name", "email"]
}

A schema validator checks a candidate JSON against the schema and reports failures: “missing required field ‘email’”, “age is -5, must be >= 0”, etc.

Popular implementations:

Ajv (JavaScript) — fast, widely used, supports drafts 04 through 2020-12.
jsonschema (Python) — reference implementation feel, supports same drafts.
JSON Schema Validator (Java) — many options.
Most languages have implementations.

The tool above doesn’t include schema validation. Use Ajv or similar for that.

Validation vs parsing

In a typical Node.js or browser handler:

let data;
try {
  data = JSON.parse(text);   // syntactic
} catch (e) {
  return { error: "Invalid JSON: " + e.message };
}
const result = schema.validate(data);  // schematic
if (!result.valid) {
  return { error: "Invalid shape: " + result.errors[0].message };
}

The two layers catch different failures: parse errors are usually transport corruption or the wrong format; schema errors are usually wrong-shape data from a misbehaving caller.

When to use which

Use the tool above when you have a JSON string and want to check it’s parseable. Useful for debugging API responses, configuration files, or copy-pasted JSON.
Use JSON Schema when you have a stable shape you want to enforce — a configuration file, an API request body, a stored document.
Use TypeScript/Pydantic/Zod when the validator is integrated with your language types. These give compile-time and runtime checks together.

Common pitfalls

Treating “valid JSON” as “correct data.” Validation passes; values can still be wrong.
Confusing JSON with JavaScript. A snippet you copied from JS code ({name: "Alice"} — unquoted keys) is valid JS, invalid JSON.
JSONC and JSON5 in tools that expect strict JSON. Stripping the comments first is sometimes the answer; switching to a permissive parser is sometimes better.
BOM at the start. A UTF-8 BOM can make the parser see the first byte as a non-JSON character. Strip BOMs before parsing.
Trailing whitespace or newlines. Allowed by spec, but very strict parsers sometimes reject. The tool above tolerates them.
Duplicate keys. Technically allowed; behavior varies by parser. Most JS parsers keep the last value silently. JSON Schema can flag this with uniqueItems.

For other JSON tools, see JSON formatter, JSON minifier, JSON diff.

JSON Validator