Utilia

JSON Schema Validator

Validate a JSON document against a JSON Schema in your browser. Every error is listed with its instance path, keyword and schema path.

How to validate JSON against a schema

  1. Paste your schema in JSON Schema and your data in JSON document, or pick a ready-made case from Example.
  2. Leave Draft on Automatic ($schema) to use the version named by the schema’s $schema, or force draft 4, 7, 2019-09 or 2020-12.
  3. Validation runs as you type; Validate runs it again. Format both re-indents the two texts.
  4. Read the result: a green line when the document is valid, otherwise a table of errors.

Reading the error table

Each row is one failed rule:

  • Instance path is a JSON Pointer to the value that failed. /roles/1 is the second item of roles; (root) is the whole document.
  • Keyword is the schema rule that failed: type, required, minimum, pattern, format, additionalProperties and so on.
  • Message explains the failure, for example 0 is less than 1.
  • Schema path points to the keyword inside the schema, such as /properties/id/minimum, so you can find the rule quickly.

Validation does not stop at the first problem: all errors are listed. When an object property fails, the validator reports a summary (“Property “id” does not match schema”) followed by the precise reason. Show only the most specific errors hides those summaries; untick it to see the full chain. Errors under anyOf and oneOf are always kept together with the specific errors of each branch, because they only make sense together.

What is supported

  • Drafts: 4, 6 (validated with the draft 7 rules), 7, 2019-09 and 2020-12, including $defs/definitions, local $ref, if/then/else, dependentRequired, dependentSchemas, prefixItems, unevaluatedProperties and unevaluatedItems.
  • Formats: date, time, date-time, duration, email, hostname, ipv4, ipv6, uri, uri-reference, uri-template, uuid, regex, json-pointer and relative-json-pointer are checked. Unknown formats are ignored, as the specification allows.
  • References: $ref can point anywhere inside the schema, including to an $id it declares. Remote schemas are never downloaded; a reference to another URL is reported as unresolved.

This tool validates documents against your schema. It does not check that the schema itself follows the meta-schema, but it warns about unknown type names such as "strin" or "int", a common typo that validators otherwise ignore silently.

The examples

  • User profile (2020-12): required, string lengths, format: email, an enum inside items, uniqueItems and additionalProperties: false.
  • Product list with $ref (draft-07): an array whose items reference #/definitions/product, with a pattern for the SKU and an exclusiveMinimum price.
  • Config with if/then (2019-09): a certificate required only in HTTPS mode, a oneOf between e-mail and URI, and numeric limits.

Each example comes with a document containing deliberate mistakes, so you can see what the errors look like.

Frequently asked questions

Is my data uploaded?

No. The schema and the document are validated in your browser; nothing is sent to a server.

Why is my schema's $ref "unresolved"?

The validator only knows the schema you pasted. A $ref to another file or URL cannot be followed; copy the referenced definitions into $defs and point to #/$defs/… instead.

Which draft should I use?

Use the one your project targets, and declare it with $schema. For new schemas, 2020-12 is the current version; OpenAPI 3.1 also uses it.

Why does integer reject 2.0?

It doesn’t: JSON Schema treats 2.0 as an integer because its value is whole. 2.5 fails "type": "integer".

Does it work offline?

Yes. Once the page has loaded and you have run a first validation (which loads the validator), no connection is needed.