JSON Schema Generator
Turn an example document into a JSON Schema, and say plainly what the example cannot settle.
One Example Is A Start, Not A Specification
Writing a JSON Schema by hand is tedious and writing it from an example is quick, so almost everybody starts from an example. The catch is that an example under-determines the schema in ways that are easy to miss: an empty array says nothing about what belongs in it, a null says nothing about the type it stands in for, and a field that happens to be present in this record may be optional in every other one.
This generator does the tedious part and then tells you exactly which parts the example could not settle, so you know what is left to finish by hand rather than discovering it when validation rejects real data.
Key features
- Draft 2020-12 and draft 07 — the current standard and the one most tooling still expects.
- Formats detected — dates, date-times, emails, URIs, UUIDs and IPv4 addresses recognised from their shape.
- Arrays of mixed objects merged — every key seen is kept, and only keys present in every element are required.
- The gaps are named — each null and each empty array is listed by path rather than quietly guessed at.
- Nothing is uploaded — the document stays in the page, which matters when it is a real API response.
This tool runs entirely inside your browser using native Web APIs. Your files and text are never uploaded to a server, never logged and never shared with third parties.
How to use: JSON Schema Generator
- Paste your JSON
A single representative record, or an array of several — more elements give a better schema. - Choose a draft
2020-12 unless something in your stack needs draft 07. - Set the strictness
Decide whether present keys are required and whether extra properties are allowed. - Read the notes, then copy
Anything the example could not settle is listed. Fix those by hand.
Technical specifications
| Processing location | Entirely in your browser — no server round trip |
|---|---|
| Data uploaded | None. Files and text never leave your device |
| Price | Free — no account, no trial, no usage cap |
| Category | Developer |
| Works offline | Yes, once the page has loaded |
| Browser support | Chrome 90+, Edge 90+, Firefox 90+, Safari 15+ |
| Interface languages | English, 中文, हिन्दी, Español, العربية |
Frequently asked questions
Why is a null typed as "null or string"?
Because the example gives no other information. A null tells you the field can be absent in value but not what it holds when it is present. The generator lists every one of them so you can replace the guess with the real type — leaving it as it stands would produce a schema that accepts a string where you meant a number.
Should every key be required?
Only if it genuinely is. The default marks everything present as required because that is the stricter reading and it is easier to remove a constraint than to notice a missing one. If your example is one record out of many, feed the generator an array of several instead and it will require only what appears in all of them.
What does "no extra properties" do?
It sets additionalProperties to false, which rejects any key the schema does not name. That is right for a closed message format and wrong for anything you intend to extend, because adding a field then becomes a breaking change for every existing validator.
Can I use this for OpenAPI?
Mostly. OpenAPI 3.1 uses JSON Schema 2020-12 directly, so the output drops in. OpenAPI 3.0 uses an older dialect with small differences — nullable instead of a null type, and no examples keyword in the same place — so a 3.0 spec needs a little adjustment.
Why did it not detect my date format?
Formats are inferred from the shape of the string, and only the common ones are recognised. A date written as 03/04/2026 is ambiguous between two continents, so it is deliberately left as a plain string rather than labelled wrongly. ISO 8601 dates are detected reliably.