JSON Schema generator
Paste one or more sample JSON documents; the tool infers types, required fields, nested objects and arrays and writes a draft 2020-12 schema. It detects date, e-mail, URI and UUID formats, suggests an enum for a few repeating strings and automatically checks the schema it produced against your samples.
Paste a single object, an array or several samples. For several samples use an array (each item is one sample) or one JSON document per line; the more samples you give, the better the required/optional split.
The schema is generated in your browser; your sample JSON is not sent anywhere or stored.
Generated schema
Paste sample JSON or load the example.
The generated schema is a starting draft: it describes only what the samples showed. Unseen values, range limits (minimum, maxLength), patterns and business rules are missing; an enum suggestion excludes valid but unseen values and format detection is heuristic. Review and correct the schema against the real rules of your systems, then use it with a validator in your own stack (e.g. Ajv, jsonschema).
Would you like to design the data contracts between your systems (schema, versioning, validation and error handling) together?
Request a call01
How to use
A
Paste one or more sample JSON documents (an array or one document per line); the more and the more varied the samples, the better the schema.
B
Adjust the required fields, multiple types, format detection, the enum threshold and additionalProperties; the schema updates at once.
C
Copy or download the schema. The "Self-check" indicator tells you whether the schema accepts every sample; then work the schema over against your real rules.
02
How is a schema inferred from samples?
The tool merges all the samples into one structure: for each field it counts which types were seen how often, in which samples each field of an object appears, and what the items of arrays look like. It then turns that count into JSON Schema: properties and required for objects, items for arrays, type for values.
Every number with an integer value becomes integer, and number is written if a fractional number was seen (number includes integer). In JSON 1 and 1.0 are the same number; the parser does not tell them apart. Empty arrays carry no type information; the item schema comes only from arrays in other samples.
03
required, null and multiple types
By default a field is required if it is present in every sample in which that object appears; if it is missing even once it stays optional. That is why a single sample makes every field required: to see that a field is optional you need a sample that lacks it. If a null value is seen, null is added to the type list ("type": ["string", "null"]); a field that is absent altogether is a different thing and is expressed by required.
If several types are seen at the same location there are two ways to write it: a type array (short; properties, items and format apply only to their own type) or anyOf (each type its own schema). Arrays are treated as lists, not tuples: all items merge into one items schema.
04
Review the generated schema
Samples only describe what you have seen. Be especially careful in three places: an enum suggestion is made only for a few repeating text values, but you are the one who knows whether those values really are a closed set; format is added only if all the strings at that location fit the same format and is heuristic; additionalProperties: false breaks when the other side adds a field later.
The tool checks the schema it produced against every sample with the JSON Schema validator. That lets you be sure the schema accepts your samples (you see it if an option such as "Every field seen" leaves samples out), but it does not prove that the schema expresses your business rules correctly.
FAQ
- Is a single sample enough?
- A schema comes out, but a weak one. In one sample every field looks required, every type looks like the only type, and null or differently typed values are not seen. Give as many and as varied samples as you can: ones where the field is missing, null, with empty arrays and with extreme values.
- Why does the required list differ from what I expected?
- By default only fields that are present in every sample in which the object appears are required. Fields that are required in your contract but always filled in your samples come out required anyway; the ones that should be optional you can only convey with a sample that lacks them. If needed set the option to "None" and add the required fields by hand.
- Can I trust the format and enum suggestions?
- As a draft. format is added only if all strings at that location fit date-time, date, uuid, e-mail or URI; a single sample can satisfy that rule by chance. enum is suggested only for a few repeating values and excludes valid values that were not seen; keep it if it really is a closed set, otherwise delete it.
- What happens if a field arrives both as an integer and as a fraction?
- number is written; in JSON Schema number includes integer. If only whole numbers are seen, integer is written. A value such as 1.0 is the same number as 1 in JSON and counts as an integer; if you supply a field that is expected to be fractional only with samples containing 1, 2, 3 you get integer.
- When is additionalProperties: false right?
- When you decide exactly which fields the other side may send (your own API, an import file). When you validate another system's response it is usually wrong: your validation breaks when that system adds a new field. It is off by default, which means unknown fields are allowed.
- What if the items of an array have different types?
- They all merge into one items schema: if items contain both text and numbers, items gets "type": ["integer", "string"] (or anyOf). Position-dependent (tuple) arrays are not inferred; for that you have to write prefixItems by hand.
Let's design your data contracts together
We design schemas, versioning and error handling for the data flows between CRM, ERP and third-party systems. Let's talk through your current flow in a free discovery call.