JSON Schema Generator
Paste a JSON document and get a JSON Schema that describes it. Types, nested objects, array items, required properties and common string formats are inferred from your sample. Everything happens in your browser.
- Runs in your browser
- No sign-up
- Free to use
How to use JSON Schema Generator
- Paste a representative JSON sample or open a .json file.
- Choose the schema version and the options you want.
- The schema is generated as you type; review required fields and types.
- Copy the schema or download it as schema.json.
JSON Schema Generator features
Type inference
Distinguishes string, integer, number, boolean, null, object and array, and combines them where a field varies.
Merged array items
All objects in a list are merged into one item schema; a property is required only if every item has it.
Format detection
Recognises date-time, date, time, email, URI, UUID and IPv4 strings.
Nullable fields
A field that is null in some places and a value in others gets both types.
Two drafts
Outputs draft 2020-12 or the widely supported draft-07.
Optional strictness
Can forbid properties that are not in the sample, and add example values.
When to use JSON Schema Generator
- Starting a schema for an existing API response.
- Documenting the shape of a configuration file.
- Creating validation rules for incoming webhooks.
- Producing a schema for editor autocompletion of JSON or YAML files.
JSON Schema Generator FAQ
How accurate is a generated schema?
It describes exactly what is in your sample, no more. A field that happens to be an integer in the sample is typed integer even if the API can return decimals, and an optional field that is present looks required. Use a sample that shows the variety of real data, then review the result.
How are required properties decided?
At the top level, every property in the sample is listed as required. Inside arrays of objects, a property is required only if all items contain it. Turn the option off to leave required out entirely.
What does “No extra properties” do?
It adds "additionalProperties": false to every object, so validation fails when data contains a property that the schema does not list. That catches typos in property names, at the cost of rejecting new fields added later.
Which draft should I choose?
Draft 2020-12 is the current version. Draft-07 is still the most widely supported by validators, editors and code generators. For a schema produced by this tool the two differ only in the $schema line.
Why does a field have several types?
Because the sample contained different kinds of values at that position, for example a string in one array item and null in another. JSON Schema expresses that as "type": ["string", "null"].
Are formats enforced by validators?
It depends on the validator. In recent drafts, format is an annotation by default and is only checked when format validation is switched on. Treat it as documentation unless you have enabled it.
From example to contract
JSON Schema is a vocabulary for describing JSON documents: which properties an object has, what type each value is, which are mandatory, what range or pattern a value must satisfy. A schema is itself JSON. Validators in every major language can check data against it, editors use it for autocompletion and inline errors, and tools generate types, forms and documentation from it.
Writing a schema by hand for a large document is tedious, which is where inference helps. The generator walks through the sample and records, for each position, which types occur. Objects become a list of properties. Arrays are assumed to be lists of similar things, so all their elements are folded into one description. Where elements differ, the union is kept: a property missing from some elements becomes optional, a value that is sometimes null becomes nullable.
Inference has a clear limit. A sample shows what one document looks like, and a schema states what all valid documents must look like. The first cannot fully determine the second. No sample can tell the generator that an integer must be positive, that a string is one of five allowed values, or that a missing field is acceptable. Those are decisions about the data, and they have to be added by someone who knows it: enum for fixed sets of values, minimum and maximum for ranges, pattern for identifiers, and a careful look at required.
A practical workflow is to generate, tighten, and then test. Generate the schema from the richest sample available. Edit it to express the real rules. Then validate several real documents against it, including ones that should fail. A schema that has been through that process is a dependable contract between the systems that produce and consume the data.