JSON Schema Validator

Validating JSON Against a Schema: What, Why, and How

JSON Schema turns ad-hoc validation ("if data.user.email exists and looks like an email, and data.user.age is a number...") into a declarative document that any validator can enforce. This validator runs the same checks the big libraries (Ajv, jsonschema, network-nt/json-schema-validator) do, in the same way, but locally in your browser, perfect for debugging API contracts, configuration files, or webhook payloads without ever leaving the page.

What Schema Validation Actually Checks

For each node in your data, the validator evaluates every applicable assertion in the schema:

• Types. Is this a string? A number? An object? A null? Type mismatches are the most common failure.
• Constraints on primitives. minLength, maxLength, pattern for strings. minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf for numbers. format for both.
• Constraints on objects. required (list of mandatory keys), properties (subschemas per key), additionalProperties (allow/disallow unknown keys), patternProperties (regex-keyed subschemas), dependencies.
• Constraints on arrays. items (subschema for every element), minItems, maxItems, uniqueItems, contains.
• Combinators. allOf (every subschema must pass), anyOf (at least one must pass), oneOf (exactly one must pass), not (the subschema must fail).
• Enums and constants. enum (value must be one of), const (must equal exactly this).

The validator runs every applicable assertion and accumulates errors rather than failing on the first one. You see the full set of problems in one pass.

Error Output That Pinpoints the Problem

Generic validators report "validation failed" and leave you to find where. Good validators report exact paths. This validator reports each error as:

For deeply nested schemas, this is the difference between five minutes of bisecting and instant comprehension.

Combinator Errors: The Hard Part

oneOf and anyOf are the most expressive, and the most confusing, schema constructs. A discriminated union like:

When this fails, naive validators report "does not match any schema". This validator reports per-branch failures, so you see "branch 0 failed because userId is missing; branch 1 failed because systemKey is missing", which immediately tells you which intent the data was closest to.

For schemas using a discriminator pattern (type field selecting which branch applies), consider using if/then/else instead of oneOf, error messages are dramatically clearer.

Refs and Modular Schemas

Real schemas reuse subschemas heavily via $ref. The validator resolves all local refs (those pointing into the same document, like #/definitions/Address) automatically. Remote refs (URLs to other files) are blocked for security in the browser context, bundle them with a tool like json-schema-ref-parser before pasting if your schema relies on external files.

Validating at API Boundaries

The highest-value use of JSON Schema is at runtime, in production, as a defensive layer at API ingress and egress:

• Incoming requests, reject malformed payloads at the gateway with a precise error message instead of relying on each handler to validate.
• Outgoing responses, in integration tests, validate against the schema you publish to clients. Catches contract drift before it ships.
• Webhook events, schema-validate every inbound webhook; a small format change at the sender shouldn't take down your processor.
• Configuration files, validate Kubernetes ConfigMaps, Helm values, and service configs at deploy time.

This browser-side validator is for the debugging path, when something failed and you need to know exactly why. Once you're satisfied with the schema, port the same JSON to your runtime validator (Ajv in Node, jsonschema in Python, networknt in Java) and the behavior will match.

Schema Versioning

Schemas evolve, and consumers don't all upgrade in lockstep. Best practices:

• Use $id to version your schemas: https://example.com/schemas/user-v3.json.
• Never silently break a contract. Adding optional fields is safe; making a previously optional field required is breaking.
• Stamp data with the schema version it was produced against. Future processors can validate against the right version.

Privacy and Trust

A schema can reveal sensitive API surface; data can include PII. Both stay in your browser when you use this validator. You can confidently paste production payloads to debug a failed validation without crossing any data-residency or compliance boundaries.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["userId", "amount", "currency"],
  "properties": {
    "userId":   {"type": "string", "pattern": "^u_[A-Za-z0-9]+$"},
    "amount":   {"type": "integer", "minimum": 1},
    "currency": {"type": "string", "enum": ["USD","EUR","GBP"]}
  }
}

{"userId":"u_8a2f","amount":1299}

FAIL  required          path: ""          missing "currency"

{
  "type": "object",
  "properties": {"eventName": {"type": "string"}, "userId": {"type": "string"}},
  "additionalProperties": false
}

{"eventNmae":"checkout_completed","userId":"u_8a2f"}

FAIL  additionalProperties   path: ""   unexpected key "eventNmae"

{
  "oneOf": [
    {"properties":{"type":{"const":"payment.succeeded"},"chargeId":{"type":"string"}},
     "required":["type","chargeId"]},
    {"properties":{"type":{"const":"payment.refunded"},"refundId":{"type":"string"}},
     "required":["type","refundId"]}
  ]
}

FAIL  oneOf  branch 0: required → missing "chargeId"
              branch 1: const    → "type" must be "payment.refunded"