What the JSON Schema Inferrer does
This tool writes a JSON Schema (draft 2020-12) from example JSON - one document, an array of documents, or JSON Lines - and shows the evidence behind every rule it wrote: how many samples contained each field, which types were seen, and where the samples disagree with each other.
Inference is guesswork made visible. One sample cannot tell you which fields are optional, whether a number can be fractional or whether a string is always an email. So instead of presenting the schema as fact, this page gives each field a confidence based on how many samples support it and lists the conflicts you need to decide by hand.
How to use it
- Paste your samples. An array of objects is read as many samples, and text with one JSON document per line is read as JSON Lines; choose a mode yourself if the automatic reading is wrong.
- Optionally set a title, the enum limit (write an
enumwhen a text field keeps repeating a handful of values) and whether to detect formats. - Choose Infer schema and read the Conflicts tab first - those are the places where the samples disagree.
- Check Field evidence: a field seen in fewer samples than its parent object is optional, and low confidence means too few samples to be sure.
- Copy or download the schema, then tighten it by hand - add
maxLength, ranges and descriptions that no amount of sample data can reveal.
Reading the results
Required means the field appeared in every object at that position. With six samples that is decent evidence; with one it is none at all, which is why confidence is low below 5 observations, medium from 5 and high from 20.
Mixed types means the same field held, for example, a number in one sample and a string in another. The schema records the union so every sample stays valid, but usually one of them is a bug in the producer.
A format is written only when every non-empty value matched it. When most but not all match, the tool reports the split rather than writing a format that some of your own data would fail.
The last tile re-validates every sample against the schema just written. It should always read all of them; if it does not, something in the data is outside what the inference supports and is worth reporting.
Worked example: six customer records in JSON Lines
Load the example: six account records with id, email, plan, seats, createdAt, tags, a nested billing object, and a referrer URL on two of them.
The result has 11 fields. referrer is present in 2 of 6 objects, so it is optional; every other top-level field is required. id gets format: uuid, email gets format: email and referrer gets format: uri. billing.vatId is null in 3 of 6 records, so its type is ["string", "null"]. plan repeats three values over six records, so with the enum limit of 5 it becomes enum: ["free", "pro", "team"].
Two conflicts are reported. seats was a number five times and the string "3" once - almost certainly a producer bug, recorded as ["number", "string"] so you notice it. And 5 of 6 createdAt values are date-times, but one is the plain date 2025-02-08, so no format is written. All six samples validate against the inferred schema.
What inference cannot know
Samples show what happened, not what is allowed. The schema will not contain a maximum length, a numeric range, a pattern, or the full list of enum values unless your samples happen to demonstrate it - and even then, the tool only writes the enum when you ask it to and the values clearly repeat.
Treat the output as a first draft for a human to finish: confirm each required field against the producer's documentation, choose between the types in each conflict, and add descriptions. Then use the JSON Schema Validator to check new data against the finished schema.
Limitations: what the result does not prove
- Rules are drawn only from the samples provided. A field that is sometimes missing in production but present in every sample you pasted will be marked required.
- Integers and fractional numbers seen at the same place are merged into
number; a field where only whole numbers were seen is written asinteger, even if fractions are allowed. - Arrays are summarised with a single item schema. Tuple-like arrays, where position matters, are not detected.
- Input is capped at 5 MB and 5,000 samples, with at most 5,000 distinct field paths, so a very varied data set is refused rather than summarised badly.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- JSON Schema 2020-12 - checked 19 Sep 2026
- JSON Schema Core 2020-12
- JSON Schema Validation 2020-12 - defined formats
- JSON Lines format
- RFC 8259 - The JSON data interchange format
Frequently asked questions
How many JSON samples do I need to infer a good schema?
Enough to show every optional field both present and absent, and every type a field can take. In practice that means at least a few dozen varied records for a real API; the page marks a field's confidence as high only from 20 observations.
Why is a field I know is optional marked as required?
Because it appeared in every sample you pasted. Inference can only generalise from what it sees. Add a sample without the field, or remove it from the required list by hand.
Which JSON Schema draft does the output use?
Draft 2020-12, declared with the $schema keyword. The keywords written - type, properties, required, items, format, enum and anyOf - mean the same in draft-07, so you can change the $schema line if your validator needs the older draft.
Can it read JSON Lines or NDJSON logs?
Yes. Paste one JSON document per line, or drop a .jsonl or .ndjson file. Blank lines are skipped, and a line that is not valid JSON is reported with its line number.
Why did it not detect the date-time format on my timestamps?
At least one non-empty value at that position did not match RFC 3339 date-time - often a date without a time, or a timestamp without a time zone. The Conflicts tab says how many matched, so you can fix the data or accept the looser schema.
What happens when the same field is sometimes an object and sometimes a list?
It is written as anyOf with one schema per shape, and listed as a conflict. Unions like this are legal but awkward for clients, so it is worth confirming with whoever produces the data.
Last reviewed by the A2Z.Tools team against the sources listed above.
