JSON Schema Validator

Supported keywords

Core: type, enum, const, multipleOf, maximum, minimum, exclusiveMaximum, exclusiveMinimum, maxLength, minLength, pattern, maxItems, minItems, uniqueItems, maxContains, minContains, maxProperties, minProperties, required, dependentRequired.

Composition: allOf, anyOf, oneOf, not.

Applicators: properties, patternProperties, additionalProperties, items, prefixItems, contains, propertyNames.

Conditionals: if, then, else, dependentSchemas.

References: $ref, $defs, $id, $anchor.

Formats (with validation when enabled): date-time, date, time, duration, email, hostname, ipv4, ipv6, uri, uuid, regex.

Error output

FAIL  /user/email        format            "not-an-email" is not a valid "email"
FAIL  /user/age          minimum           -3 is less than the minimum 0
FAIL  /orders/0/total    type              "42" is not of type "number"
FAIL  /                  required          missing required property "shippingAddress"

Every error includes the path and the keyword that failed, making it fast to locate in your editor.

Draft differences that bite

Set the right draft; validating a draft-04 schema as 2020-12 will misinterpret id and some other subtleties.

Typical workflows

• API contract testing: before a deploy, run the generated/updated OpenAPI schema against real sample responses.
• Config hardening: validate every YAML/JSON config in CI against a schema before merging.
• Data ingest: reject payloads that do not match the expected shape early, with a clear error message.

Common mistakes

• Forgetting format enforcement. By default, most validators treat unknown formats as annotation-only. Enable strict-format validation to actually reject bad emails and dates.
• Overusing oneOf. If two branches of oneOf overlap, the document will fail (it must match exactly one). Use anyOf or discriminator patterns.
• Tight schemas with additionalProperties: false. Adding a new optional field becomes a breaking change. Omit it unless you truly want a closed object.