JSON Schema Validator

Backend developers, API designers, and QA engineers use this tool whenever a JSON payload must be checked against a structural contract before it reaches production. It runs the moment you paste a schema and a data document — no build step, no CLI, no server round trip. The tool catches missing required fields, type mismatches, out-of-range numbers, and unrecognized properties that would otherwise surface as runtime errors days later. Because validation happens in your browser, you can safely check proprietary API responses, staging database exports, and internal config files without sending them anywhere.

JSON Schema

JSON Data

How This Validator Processes Your Schema

When you click Validate, the tool first parses both textareas with JSON.parse(). A syntax failure in either pane halts the run and reports the parse error before any schema logic executes. Once both documents parse as valid JSON, the validator walks the data tree node-by-node against the schema tree, starting at the root.

For every node, the engine resolves any $ref by following the JSON Pointer inside the same schema document. It then evaluates keywords in a fixed order: type first (so type mismatches short-circuit and avoid confusing follow-on errors), then const and enum for value constraints, then numeric/string bounds, then array rules (items, minItems, uniqueItems), and finally object rules (required, properties, additionalProperties). Combinator keywords (allOf, anyOf, oneOf, not) are evaluated after the type check so each branch gets a clean sub-validation.

The format keyword checks common string patterns — email, URI, date, date-time, time, IPv4, hostname — using local regular expressions. Unknown format values are ignored, matching the draft-07 behavior where format is an annotation by default. The tool enforces a depth limit of 50 recursion levels to prevent stack overflow on pathologically nested schemas.

Every violation is recorded as an object with a path (JSON Pointer per RFC 6901) and a human-readable message. The results panel renders them as a flat list so you can scan and jump to the exact location in your data. Nothing leaves your browser — no fetch calls, no analytics on content, no temporary storage.

Before and After: Real Validation Examples

Example 1 — Missing required property

Schema input:

{
  "type": "object",
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" }
  },
  "required": ["id", "email"]
}

Data input:

{ "id": 42 }

Validator output:

✗ Missing required property "email"
  path: ""

Example 2 — Nested type and range errors

Schema input:

{
  "type": "object",
  "properties": {
    "user": {
      "type": "object",
      "properties": {
        "age": { "type": "integer", "minimum": 0, "maximum": 150 },
        "role": { "enum": ["admin", "editor", "viewer"] }
      },
      "required": ["age", "role"]
    }
  },
  "required": ["user"]
}

Data input:

{
  "user": {
    "age": -5,
    "role": "superadmin"
  }
}

Validator output:

✗ Value -5 is less than minimum 0
  path: "/user/age"
✗ Value must be one of: "admin", "editor", "viewer"
  path: "/user/role"

Example 3 — Passing validation

Schema input:

{
  "type": "object",
  "properties": {
    "tags": {
      "type": "array",
      "items": { "type": "string", "minLength": 1 },
      "minItems": 1,
      "uniqueItems": true
    },
    "score": { "type": "number", "minimum": 0, "maximum": 100 }
  },
  "required": ["tags", "score"],
  "additionalProperties": false
}

Data input:

{ "tags": ["seo", "dev"], "score": 87.5 }

Validator output:

✓ Valid — data matches the schema

Where Teams Apply This Tool

Developer

Check that a third-party API response matches the contract your client code expects before writing parsing logic.
Validate environment config files in CI — a schema catches a missing port number before the container starts.
Test form submission payloads against a schema shared between frontend and backend teams.
Debug a failing integration test by isolating which field diverges from the agreed schema.

Production

Run schema checks as a pre-commit hook so malformed JSON never enters the repository.
Validate webhook payloads at the edge before forwarding them to internal services.
Use the same schema in staging and production to confirm a migration did not change the payload shape.
Audit exported data dumps against the canonical schema before loading them into analytics pipelines.

Workflow

Share a schema with a client, then paste their sample payload here to confirm it conforms.
Run validation during code review: paste the PR's test fixture and the schema side by side.
Pair with a JSON formatter to first clean the payload, then validate it against the schema.
Document the schema behavior by saving passing and failing examples as team knowledge base entries.

Common Mistakes and Troubleshooting

Schema uses single quotes or unquoted keys

JSON requires double quotes around every key and string. A schema copied from JavaScript source often uses single quotes or bare identifiers — 'type': 'object' instead of "type": "object". The parser rejects this with a syntax error before validation begins. Run the schema through the JSON Formatter first to normalize quoting.

Type "integer" rejects 3.0

The schema keyword "type": "integer" requires a whole number. In JSON, 3.0 parses as a float, so it fails the integer check. If your data source emits floats for whole values (common in databases and Python serializers), either change the schema to "number" or round the value before validation.

additionalProperties: false blocks extra keys

Setting "additionalProperties": false rejects any key not listed in properties. This is useful for strict contracts but causes false failures when a backend adds a new field. If you only want to warn rather than fail, remove the flag or declare the extra keys explicitly.

Trailing commas and comments

Both the schema and data inputs must be strict JSON — no trailing commas, no // comments. This differs from JSONC and JSON5. If your file contains comments, strip them first with a minifier or editor that supports JSONC-to-JSON conversion. The tool reports a parse error with the offending character position.

Circular $ref causes a depth limit

Self-referential schemas (a tree node whose children are the same node) will recurse until the depth limit of 50 is hit. The validator stops rather than crashing, but you may see partial results. For deeply recursive data, consider flattening the schema or using a bounded depth definition.

oneOf fails when two branches match

If a value satisfies two sub-schemas in a oneOf, the validator reports a failure because oneOf demands exactly one match. This often happens when two branches are not actually mutually exclusive — for example, two object schemas that both allow the same property set. Narrow one branch or switch to anyOf.

Schema Authoring Best Practices

✓ Start strict: set additionalProperties: false and list all required fields during initial development. Loosen constraints later rather than tightening them after launch.
✓ Add descriptions: attach a description string to every property. Many API doc generators and form builders read this field directly.
✓ Use enums for closed sets: status fields, roles, and category codes should use enum rather than a bare type: "string".
✓ Declare a $schema: add "$schema": "http://json-schema.org/draft-07/schema#" at the top so editors enable autocomplete and linting.

Workflow and Performance Tips

✓ Validate in pairs: keep a passing fixture and a failing fixture in your test suite so schema regressions are caught immediately.
✓ Format before validating: use the JSON Formatter to normalize indentation and surface syntax errors with line numbers first.
✓ Generate schemas from data: if you have sample data but no schema, run it through the JSON Schema Generator to produce a starting draft.
✓ Keep schemas local: this tool makes no network calls, so it is safe for air-gapped environments and pre-release data.

Frequently Asked Questions

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

JSON validation checks whether a string follows the syntax rules of RFC 8259 — balanced braces, quoted keys, valid numbers. JSON Schema validation goes deeper: it checks whether the parsed data matches a structural contract you define. A schema can require specific property names, enforce numeric ranges, limit string lengths, or restrict values to an enum. Two documents can both be valid JSON but only one satisfies a given schema.

Which JSON Schema drafts does this tool support? ▼

The validator handles draft-07 and the 2020-12 vocabulary for the keywords that cover the most common validation scenarios: type, properties, required, items, enum, const, minimum, maximum, minLength, maxLength, pattern, format, allOf, anyOf, oneOf, not, additionalProperties, and internal $ref pointers. It does not implement the full meta-schema or remote $ref resolution, since that would require network access and defeat the browser-side privacy model.

Can I use $ref to reference definitions inside the schema? ▼

Yes. Internal references like #/definitions/Address or #/$defs/Address are resolved at validation time. The validator walks the JSON Pointer path inside the same schema document and validates against the resolved sub-schema. Remote references (URLs) are not fetched, because all processing stays inside your browser with no network calls.

What does the error path notation mean in the results? ▼

Each error includes a JSON Pointer path that tells you exactly where in the data the violation occurred. An empty path means the root object failed. The path /items/2/price means the third element of the top-level items array has a problem with its price property. This notation follows RFC 6901 and is the same format used by most API testing tools and CI pipelines.

How does anyOf differ from oneOf and allOf? ▼

allOf requires the data to satisfy every sub-schema simultaneously — useful for combining a base shape with additional constraints. anyOf requires at least one sub-schema to pass, which is useful for union types where several shapes are acceptable. oneOf requires exactly one to pass and fails if two or more match, which enforces strict mutual exclusivity. Choosing the wrong combinator is one of the most common schema-authoring mistakes.

Is my schema and data uploaded to any server? ▼

No. Both the schema and data textareas are processed entirely in your browser using a local JavaScript engine. The tool makes zero network requests with your input. This makes it safe to validate proprietary API payloads, internal configuration files, or pre-release database dumps without exposing them to third-party services.

Why does my schema report an error even though the data looks correct? ▼

Common causes include: a required property that exists but under a slightly different key name, a type mismatch where the schema says "integer" but the JSON value is 3.0 (a float), or an additionalProperties: false flag rejecting a key that was not declared in properties. The JSON Pointer path in each error message points to the exact location so you can trace the mismatch quickly.