JSON Schema Generator

About Schema Generator

Reads a document and writes the schema it satisfies. JSON, XML, YAML, TOML, TOON, INI, .env, .properties and HCL produce a JSON Schema, an Avro schema or a .proto; XML produces an XSD. It is a first draft rather than a contract, and the distinction matters — see below.

A sample is evidence, not a specification. Everything here is inferred from one document, so a field that happened to be present is written as required and a field that happened to be absent is not described at all. What the tool does guarantee is the narrow thing it can: the schema it writes accepts the document it was given, and the tests check exactly that by validating the sample against the result.

The three schema languages want different things, and the differences are where the thinking is. JSON Schema describes a document as it is, so nothing has to be invented. Avro and protobuf describe a *record type*, which needs names a JSON document does not carry — so a name is derived for every nested object, and for protobuf a field number is assigned to every field.

Those field numbers are the part to check before you adopt anything. They are assigned here in the order the keys appeared, and in a deployed .proto a number may never be reused for a different field: that is the one piece of a protobuf schema that is permanent. If a message already exists somewhere, take the numbers from it rather than from this.

proto2 and proto3 are not the same language. proto2 requires a label on every field; proto3 has none by default and uses optional to restore the idea of a field being genuinely absent rather than merely zero. required is never written here at all — a required field cannot be removed later without breaking every reader still holding the old schema, which is why proto3 dropped it.

Avro's optional is a union with null, since it has no concept of a missing field. Null is written as the *first* branch, because Avro takes a field's default from the first branch and "default": null is otherwise invalid — an ordering that looks arbitrary and is not.

Where it helps

• A working first draft in one step, from the document you already have in front of you.
• JSON Schema for the data formats, XSD for XML, and Avro or .proto when the target is a record type rather than a document.
• Writes proto2 and proto3 correctly rather than interchangeably: labels where proto2 needs them, optional only where proto3 means it.
• Never writes protobuf's required, which is the one label that cannot be taken back once anything is reading the schema.
• Puts null first in an Avro union, so "default": null is legal rather than merely plausible.
• Supports JSON Schema draft-04 as well as the current drafts, for the tooling that never moved on.
• Recognises dates, times, emails, UUIDs, URIs and IP addresses rather than calling everything a string.
• Runs in your browser, so a production payload never leaves the machine to become a schema.

Limits

• It infers from a sample: what was present becomes required, and what was absent is not described at all.
• One document cannot show you the optional fields, the wider ranges or the alternatives your API really allows.
• An XSD sequence follows the order this document used; a service that reorders elements will fail against it.
• No descriptions, no titles and no $ref reuse beyond XSD's named types — those are yours to add.

Frequently asked questions

Which draft does it write?

2020-12 by default, with 2019-09 and draft-07 available. The drafts differ little for a schema this shape; the $schema line is what changes.

Can I feed it several samples at once?

Yes — put them in an array and generate from that. The array's items schema merges every sample, which is exactly the wider description you want, then lift it out of the array.

Why is a field marked required when it is optional?

Because it was present everywhere it could be seen. That is all one document can tell you; remove it from required if you know better.

How do I check the schema it wrote?

Paste both into the Schema Validator. The generated schema is written to accept the document it came from, so anything else it rejects is worth reading closely.

Related tools

• Schema Validator — Check a document against a JSON Schema, .proto, Avro schema, XSD or RELAX NG
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• Table Viewer — Show the records in a JSON, XML, YAML, TOML or TOON document as a table
• 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

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