JSON Schema generator
Infer a JSON Schema or OpenAPI components from an example document, then tighten it by hand.
A schema from an example
JSON Schema describes the shape of a JSON document: which properties exist, their types, which are required. It powers validation in API gateways, editors (autocomplete in VS Code settings files), form builders and OpenAPI descriptions. Writing a schema from scratch for a large response is slow, so a common shortcut is to infer a first draft from a real example and then tighten it.
Paste a sample and choose the output: a standalone JSON Schema (draft 2020-12) or OpenAPI 3.1 component schemas. Nested objects are described inline in the first and extracted into named components with references in the second. If you paste an array of objects, the tool merges them, so a field missing from one item is not required and conflicting number types become number.
Tightening the draft
- Formats (
date-time,date,email,uri,uuid,ipv4,ipv6,hostname) are added only when every sample string matches; check them against your real data. - Add
minimum,maxLength,patternandenumconstraints where the domain has limits. - Set
additionalPropertiesto false if unknown fields should be rejected. - Turn on enums to list small repeated string sets, and review mixed types (
["string", "null"]oranyOf).
Use the JSON Schema validator on this site to test the schema against documents. The inference runs entirely in your browser.
Frequently asked questions
Which JSON Schema version is generated?
Your choice of 2020-12 (default), 2019-09, draft-07 or draft-04, declared with the $schema keyword. The result is validated against your own sample with the same engine as the Schema validator tool. Most validators (Ajv, Jackson-based libraries, Python jsonschema) support it, and the structure is close to earlier drafts.
What is the difference between JSON Schema and an OpenAPI schema?
OpenAPI 3.1 uses JSON Schema 2020-12 for its schema objects, so they are the same language. The OpenAPI output wraps each object type in components.schemas and links them with $ref, ready to paste into an API definition.
How are optional and nullable fields marked?
A field present in every sample object goes into required. A field that is null in the sample is nullable ("type": ["string", "null"]); one that is missing from some array items is left out of required.
Why does the schema allow extra properties?
A schema inferred from one example should not reject other valid documents with extra fields. Add "additionalProperties": false by hand when you want strict validation.