Are my schema and data sent anywhere?

No. Validation runs in your browser; schema and sample JSON are neither sent to a server nor stored. Even so, we recommend anonymising samples that contain customer data before you share them.

Does this tool validate my schema or the sample?

It checks the sample against the schema. It does not fully validate the schema itself against the meta-schema; it only reports obvious problems (an invalid type name, a broken regular expression, an unresolvable $ref, a wrong value type) as "problems in the schema".

Why is there a list of unsupported keywords?

If a rule that is not evaluated is skipped silently, the sample looks valid but was never checked. That is why every keyword that is in the schema but not applied, and every unknown format name, is listed separately. When this list is empty, the result is reliable for the rules that are fully supported.

Is the number 1.0 an integer?

Yes. In 2020-12 every number whose value is a whole number is an integer, including 1.0. The way it is written in the JSON text (1 or 1.0) is not distinguished, because the parser reads both as the same number.

What is the difference between pattern and format?

pattern is a regular expression and matches anywhere in the string; for a match from start to end you must write ^ and $. format is a named form (email, date…); this tool checks only five formats, simply. The email check, for example, is not a full RFC 5322 validation.

Does this replace Ajv or another validator?

No. It is for a quick check and feedback while you write a schema. In production use a library that compiles the schema, offers full draft support and detailed format checks, and version your schemas.

JSON Schema validator

Paste your schema and a sample JSON and see which field breaks which rule, with the instance path ($.items[0].qty) and the schema path. Unsupported keywords are never skipped silently, they are listed separately. The check runs in your browser; schema and data are not sent anywhere.

Free tool · Integration

JSON Schema

Sample JSON

Paste a valid JSON document into each box. The schema may be an object or true/false; draft 2020-12 rules apply.

Validation runs in your browser; schema and JSON are not sent anywhere or stored.

Result

Paste the schema and the sample JSON, or load the example, to validate.

Supported rules

Type and value: type (single or array, including integer), enum, const.
Object: properties, required, additionalProperties (boolean or schema), minProperties, maxProperties.
Array: items (after prefixItems), prefixItems, minItems, maxItems, uniqueItems.
Number: minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf (without floating-point drift: 0.3 is a multiple of 0.1).
String: minLength, maxLength (counts Unicode characters), pattern (ECMAScript regular expression, matches anywhere in the string), format (only email, date, date-time, uri, uuid; simple checks).
Composition: allOf, anyOf, oneOf, not. Reference: $ref only for pointers within the same document (#, #/$defs/name).
Annotation fields such as title, description, default, examples, $comment are ignored; every keyword other than the ones above is listed as "unsupported".
Paths: the instance path starts at the root $ ($.a[0].b, a key with a space is $["a b"]); the schema path is the rule's location in the schema document (#/properties/a/type; after a $ref, #/$defs/name/type).

This tool implements a subset of JSON Schema and is not a full conformance checker. Unsupported keywords are not evaluated, format checks are simple and the schema itself is not validated against the meta-schema. Do production validation with a library in your own stack (e.g. Ajv, jsonschema).

Would you like to design the data contracts and validation rules between your systems together? We can talk through schemas, versioning and error handling.

Request a call

How to use it

A
Paste the schema and the sample JSON to check; for broken JSON you see which box and which line and column.
B
In the violation list look at the instance path and the schema path: which field breaks which rule is written line by line.
C
Check the list of unsupported keywords; anything shown there has not been evaluated by this tool.

What is being checked?

A JSON Schema is a contract describing the structure and value rules of a JSON document: which fields are required, of which type, in which range, with which pattern. This tool tells you whether the sample satisfies the schema and lists every place where it does not; it does not stop at the first error.

In integrations a schema is the data contract between two systems: checking a webhook payload, an API response or an import file against the schema before sending catches errors in development rather than in production.

Reading the paths

Every violation has two locations. The instance path shows where the faulty value is: $.items[0].qty is the qty field of the first element of the items array, counted from the root. The schema path shows which rule was broken: #/$defs/item/properties/qty/minimum.

With $ref the schema path leads to the referenced definition, so when many fields share one definition you can see which rule the error comes from.

Scope and limits

The tool implements a commonly used subset of draft 2020-12 (type, required fields, ranges, pattern, enum, composition, $ref within the same document). Keywords such as if/then/else, patternProperties, contains, dependentRequired, unevaluatedProperties and external $ref are not evaluated; they are listed every time because a rule that is not evaluated can wrongly produce a "valid" result.

format is checked only for email, date, date-time, uri and uuid, and only simply. The specification treats format as an annotation by default; this tool applies these five formats as assertions.

FAQ

Are my schema and data sent anywhere?: No. Validation runs in your browser; schema and sample JSON are neither sent to a server nor stored. Even so, we recommend anonymising samples that contain customer data before you share them.
Does this tool validate my schema or the sample?: It checks the sample against the schema. It does not fully validate the schema itself against the meta-schema; it only reports obvious problems (an invalid type name, a broken regular expression, an unresolvable $ref, a wrong value type) as "problems in the schema".
Why is there a list of unsupported keywords?: If a rule that is not evaluated is skipped silently, the sample looks valid but was never checked. That is why every keyword that is in the schema but not applied, and every unknown format name, is listed separately. When this list is empty, the result is reliable for the rules that are fully supported.
Is the number 1.0 an integer?: Yes. In 2020-12 every number whose value is a whole number is an integer, including 1.0. The way it is written in the JSON text (1 or 1.0) is not distinguished, because the parser reads both as the same number.
What is the difference between pattern and format?: pattern is a regular expression and matches anywhere in the string; for a match from start to end you must write ^ and $. format is a named form (email, date…); this tool checks only five formats, simply. The email check, for example, is not a full RFC 5322 validation.
Does this replace Ajv or another validator?: No. It is for a quick check and feedback while you write a schema. In production use a library that compiles the schema, offers full draft support and detailed format checks, and version your schemas.

Let's design your data contracts together

We design schemas, versioning and error handling for the data flows between CRM, ERP and third-party systems. Let's talk through your current flow in a free discovery call.

Request a call Explore CRM / ERP integration →