JSON Schema Validator

About Schema Validator

Checks a document against the schema that is supposed to describe it, and reports every problem rather than the first. JSON, XML, YAML, TOML, TOON, INI, .env, .properties and HCL can be checked against a JSON Schema, an Avro schema or a .proto; XML against an XSD or RELAX NG.

JSON Schema is read by an implementation that walks the schema rather than compiling it into generated code, so a schema somebody pastes in is never turned into a function and run. Every draft from draft-04 to 2020-12 is supported, and auto takes the draft from the schema's own $schema — which is usually the right answer, because a schema written for draft-07 checked as 2020-12 can fail for reasons that have nothing to do with the document.

A .proto is read as a .proto, not as a translation of one, and the document is checked against the JSON mapping of protobuf — which is what you have when a payload arrives as JSON. That mapping has rules worth knowing: a 64-bit integer is written as a *string*, because a JSON number cannot hold one, so a quoted id is correct rather than a mistake; and a field may appear under its original name or its lowerCamelCase form, both of which are accepted here.

Avro is stricter than it looks. A union is satisfied by exactly one branch, so a field typed ["null", "string"] must be null or a string and nothing else. A field is required unless it carries a default. An int is 32 bits and a value that overruns it is an error rather than a promotion to long — which is the mistake that tends to surface in production rather than in testing.

What a schema does not say, it does not check. A valid document is one that breaks none of the rules present, which is a narrower claim than the document being correct: a field the schema says nothing about is neither required nor rejected, and a schema that describes half your payload will happily pass the other half.

Where it helps

• Reports every problem in one pass, each with the path it happened at, rather than stopping at the first.
• Reads JSON Schema from draft-04 to 2020-12, and takes the draft from the schema itself unless told otherwise.
• Checks against a real .proto — messages, nested messages, enums, repeated and map — rather than requiring it be converted first.
• Knows protobuf's JSON mapping: a 64-bit integer as a string is accepted, and so is a field under its camelCase name.
• Enforces proto2's required, and correctly does not invent an equivalent for proto3, where an unset field and a zero are the same thing.
• Checks Avro unions, enums, defaults and the 32-bit limit on int, which is the one that bites later rather than sooner.
• Walks the schema instead of compiling it, so a pasted schema is never executed.
• XSD and RELAX NG go through libxml2 itself, compiled to WebAssembly, in a worker of its own.
• Everything runs in the browser: the document and the schema both stay on your machine.

Limits

• A schema only checks what it describes. Passing means nothing was broken, not that the document is right.
• The .proto reader covers messages, nested messages, enums, repeated and map. Services, extensions, imports and options are skipped rather than guessed at — a file that leans on them is only partly checked, and import in particular means a type this cannot see.
• Protobuf is checked through its JSON mapping, not the binary wire format. A document is what can be validated; a serialised message is not.
• An Avro schema has to be JSON, because that is what an Avro schema is — it is not read in the document's format.
• Neither Avro nor protobuf validation checks defaults, aliases or schema *resolution* between a writer's and a reader's schema, which is a separate question from whether one document fits one schema.
• JSON Schema $ref to an external file is not fetched: nothing here goes to the network.
• A document valid against one draft can be invalid against another, so leaving the draft on auto is usually right.

Frequently asked questions

Why is my large id allowed as a string in a .proto check?

Because protobuf's own JSON mapping says it should be. A JSON number cannot hold a 64-bit integer exactly — anything past 2^53 loses its low bits — so int64, uint64, fixed64 and friends are written as quoted strings. A quoted id is the correct spelling, not a mistake, and both forms are accepted here.

My proto3 message has a missing field and nothing was reported. Is that right?

Yes, and it is the single most surprising thing about proto3. It has no field presence by default: an unset int32 and one holding 0 are indistinguishable, so "absent" is not a state the schema can require. Only proto2's required makes a missing field an error, and only optional in proto3 (since 3.15) restores the ability to tell unset from zero at all.

Why did Avro reject a number that looks fine?

Most likely the schema says int and the value needs a long. Avro's int is 32 bits, so anything beyond about 2.1 billion does not fit — timestamps in milliseconds and most id sequences outgrow it. That is reported here rather than quietly widened, because the failure otherwise appears in production against a real Avro writer instead.

Should I leave the draft on auto?

Usually, yes. auto reads the draft out of the schema's own $schema, which is what the schema's author declared it to be. Setting it by hand is for a schema that carries no $schema at all, or one you are deliberately testing against a different draft — a draft-07 schema read as 2020-12 can fail for reasons that have nothing to do with the document.

Which JSON Schema drafts are supported?

2020-12, 2019-09, draft-07 and draft-04. The draft comes from the schema's $schema, and can be set by hand when the schema does not say.

Can the schema be YAML?

Yes. The schema is read in the same format as the document, so a YAML document is checked against a schema written in YAML.

Why did a $ref to another file fail?

Nothing is fetched over the network. Inline the referenced schema under $defs and point the reference at it, or validate the parts separately.

Does it validate XML against a DTD?

XSD and RELAX NG are supported. A DTD inside the document is used for parsing, not as a schema to check against here.

Related tools

• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• Table Viewer — Show the records in a JSON, XML, YAML, TOML or TOON document as a table
• Path Finder — Select nodes with JSONPath or XPath
• Structure Compare — Diff two JSON, XML, YAML, TOML, TOON or HCL documents by path
• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back

More Structured Formats tools

• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back
• Structure Formatter — Pretty-print JSON, XML, YAML, TOML, TOON or HCL with a chosen indent
• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• Code Generator — Turn a JSON, YAML, XML or other document into TypeScript, Go, C#, Python, Rust and more
• Schema Generator — Write a JSON Schema, XSD, Avro schema or .proto from a document you already have
• Schema Validator — Check a document against a JSON Schema, .proto, Avro schema, XSD or RELAX NG
• Table Viewer — Show the records in a JSON, XML, YAML, TOML or TOON document as a table
• Structure Compare — Diff two JSON, XML, YAML, TOML, TOON or HCL documents by path
• Structure Repair — Fix broken JSON, YAML, XML, TOML, TOON, INI, .env, .properties and HCL, listing every repair
• Structure Minifier — Strip formatting from JSON, XML, YAML, TOML or TOON
• Path Finder — Select nodes with JSONPath or XPath
• Protobuf & Avro Decoder — Read protobuf wire bytes and Avro container files without their schema
• Expression Evaluator — Reduce a JSONPath or XPath match to a single answer