JSON Validator

Syntax validation vs schema validation

This validator answers one question: is this string parseable JSON? That is syntax validation — it checks the grammar (double quotes, matching brackets, no trailing commas) and nothing about meaning. Schema validation is a separate, second tier: it checks whether the parsed data has the right shape — required fields, correct types, allowed values. The example below is perfectly valid JSON syntax yet semantically wrong, and only a schema can catch it.

// Syntactically VALID JSON — passes this validator
{ "email": 12345, "age": "thirty" }

// A JSON Schema catches the wrong types:
{
  "type": "object",
  "required": ["email"],
  "properties": {
    "email": { "type": "string", "format": "email" },
    "age":   { "type": "integer", "minimum": 0 }
  }
}

Syntax always passes first. For the structural tier, use the JSON Schema Validator.

The four errors behind most invalid JSON

In real API payloads, four mistakes account for the large majority of validation failures. Each is something a JavaScript object literal tolerates but strict JSON rejects.

// 1. Trailing comma — JS allows it, JSON does not
{ "name": "Alice", "age": 30, }        ← remove the comma after 30

// 2. Single quotes — JSON requires double quotes
{ 'name': 'Alice' }                    → { "name": "Alice" }

// 3. Unquoted keys — a JS object literal, not JSON
{ name: "Alice", age: 30 }             → { "name": "Alice", "age": 30 }

// 4. Comments — no // or /* */ in JSON
{
  // user record
  "name": "Alice"
}                                       ← delete the comment line

How the validator reports and locates an error

The validator runs JSON.parse(), which throws a SyntaxError carrying a character offset. That offset is translated into a line and column so the error banner can say exactly where parsing failed. The key debugging habit: the reported position is where the parser noticed the problem, which is often one token after the real cause.

// A trailing comma after "age": 30
{
  "name": "Alice",
  "age": 30,
}

// Browser error — note it points at the } not the comma:
// SyntaxError: Unexpected token } in JSON at position 38
// → reported as "line 4, column 1"
// Fix: remove the comma on the previous line

Validate JSON in code: parse + try/catch, then a schema

The same two tiers apply in scripts. Tier one is a guarded parse; tier two is a schema library. JSON.parse, json.loads, and Ajv cover the cases you will hit most.

// JavaScript — syntax check with try/catch
function isValidJson(str) {
  try { JSON.parse(str); return true }
  catch (e) { console.error(e.message); return false }
}

# Python — json.loads in try/except
import json
try:
    data = json.loads(raw)
    print("Valid JSON")
except json.JSONDecodeError as e:
    print(f"Invalid at line {e.lineno}, col {e.colno}: {e.msg}")

// JavaScript schema validation — Ajv (npm i ajv)
import Ajv from 'ajv'
const ajv = new Ajv()
const validate = ajv.compile(schema)
if (!validate(data)) console.log(ajv.errorsText(validate.errors))

Strict vs lenient: why a config editor passes JSON that fails

Strict validation follows RFC 8259: double quotes only, no trailing commas, no comments, no duplicate keys. JSON.parse() — and this validator — are strict. Lenient supersets like JSON5 and JSONC accept comments, trailing commas, single quotes, and unquoted keys. A file your editor renders happily as JSON5 will throw the moment a strict consumer parses it, so validate against the dialect your target system actually uses.

// Accepted by JSON5 / JSONC, REJECTED by strict JSON.parse():
{
  // a comment
  name: 'Alice',     // unquoted key + single quotes
  tags: ['a', 'b',], // trailing comma
}

// Strict-valid equivalent:
{
  "name": "Alice",
  "tags": ["a", "b"]
}

Quick reference: error to fix

• Unexpected token } or ] — a trailing comma on the line above.
• Unexpected token ' — single quotes; switch to straight double quotes.
• Unexpected token n / t / u — an unquoted key or a JS literal (NaN, undefined).
• Unexpected non-whitespace character after JSON — two values or a stray character at the end.
• Bad control character / unexpected end of input — an unescaped newline or an unclosed string or bracket.

For the full walkthrough with all error types and fixes, see the guide on how to validate JSON. To clean up valid JSON, use the JSON Formatter; to check structure, the JSON Schema Validator.