JSON Schema Validator & Designer
betaValidate JSON against a schema, infer a schema from sample data, and design one visually
How it works
Validate mode takes a schema on the left and JSON on the right and checks them as you type with Ajv, the reference JSON Schema implementation. The draft is read from $schema (draft-04, draft-06, draft-07, 2019-09 or 2020-12; draft-07 when absent) or picked by hand; formats such as email, uri, date-time, uuid and ipv4 are checked; the schema itself is validated against the draft's meta-schema, and $ref or compile problems are reported. Every violation is listed with its path in the data, the message, the keyword that failed and its parameters. Design mode builds a schema visually: infer one from a sample JSON value (types, integer versus number, detected string formats, required keys, nullable fields — arrays merge their elements), or import the validator's schema, then edit properties, types, required flags, enums, const, formats, patterns, ranges, item and key counts and extra-key rules in a collapsible tree of any depth; the result is a standard 2020-12 schema you can copy or send straight back to the validator. Reusable definitions ($defs or definitions) are edited in their own section, a property of type $ref points at one (with completion) and shows what it allows — the referenced object's properties, required marks, formats, patterns, enums and ranges, following nested references all the way down with a guard against recursion — and a link scrolls to the definition, which says how often it is used. Rules the designer does not edit are still shown in words: if/then/else conditions (“if status = "released" then releasedAt is required”), oneOf/anyOf/allOf, and any other keyword appears as a chip and is written back unchanged. Everything runs in your browser.
Questions
Which JSON Schema drafts are supported?
draft-04, draft-06, draft-07, 2019-09 and 2020-12, via Ajv. The draft is detected from the schema's $schema URI; without one, draft-07 is assumed. You can force a draft from the selector.
Are string formats validated?
Yes. email, uri, uri-reference, hostname, ipv4, ipv6, date, time, date-time, duration, uuid, regex and json-pointer are checked with ajv-formats. Unknown formats are ignored rather than failing.
Does it check that my schema is well-formed?
Yes. The schema is validated against the draft's meta-schema first, and compile-time problems such as unresolvable $ref or invalid regular expressions are reported under “The schema itself has problems”.
How does schema inference work?
Each sample value maps to a type — integers are told apart from numbers, strings get a format when they look like an email, URI, date, date-time, time, UUID or IPv4 address. Object keys become properties and are marked required. Arrays merge their elements: a key missing from some items becomes optional, and null next to another type makes it nullable.
Can I edit an existing schema in the designer?
Yes — Open in designer converts it. Types, properties, required flags, enums, const, formats, patterns, ranges, item and key counts, extra-key rules and the $defs are editable, and the schema round-trips: what you don't change is written back exactly as it was. Anything the designer doesn't model (if/then/else, allOf, anyOf, patternProperties, custom keywords…) is shown as a chip — conditions in plain words — and preserved.
How are $ref and $defs shown?
Definitions have their own section under the tree, each with its pointer and how many references point at it. A property of type $ref names a definition (the field completes from the ones you have) and shows, under the row, what that definition allows: its type, constraints and properties with required marks, resolving references inside it as well, however deep, until a definition would repeat itself. The link next to the reference scrolls to the definition, and editing the definition updates every preview.
Is my data uploaded?
No. Validation, inference and the designer all run in your browser; nothing is sent to a server.