JSON Schema Generator

Inferring a JSON Schema, and what inference cannot know

A schema generated from a sample describes that sample, not your data model. It gets the shape right and the intent wrong, because a single example cannot tell it which fields are optional, which values are enumerations, and which nulls are meaningful.

How it works

• Walks the JSON and emits a type for each value: object, array, string, number, boolean or null.
• Marks every key present in the sample as required, since that is all a single example can support.
• Recurses into nested objects and infers array item types from the elements it finds.

inferred types
  "text"      → string
  42          → number (integer if no fraction)
  true        → boolean
  null        → null   (not "optional")
  [ ... ]     → array with inferred items
  { ... }     → object with properties

required = every key seen in the sample

Worked example

Inferring from {"id": 1, "name": "Ada", "email": null, "tags": ["a", "b"]}.

1. id → integer, name → string
2. email → null, which is almost certainly wrong: it means ["string", "null"]
3. tags → array of string
4. all four keys marked required
5. no maxLength, no format, no enum — none of that is visible in one sample

A structurally correct schema that would reject valid data. The email field typed as null accepts only null, and marking every key required rejects any record where one is absent.

Reading the result

• A null in the sample does not mean the type is null. It almost always means the field is nullable, so the correct type is a union such as ["string", "null"]. Inference cannot distinguish these and always guesses the narrower one.
• Everything is marked required because absence is invisible. Feed several documents that differ, and the union of keys tells you the true shape — with one sample you are just describing that document.
• Formats, enumerations and bounds are invisible to inference. An email, a UUID, a date and an arbitrary string all look identical; adding format, enum, minimum and maxLength is the work that turns a shape into a contract.
• Arrays are the weakest inference. An empty array gives no item type at all, and an array of mixed types usually means the sample is unrepresentative rather than that the field genuinely accepts anything.

Common questions

Why is my generated schema rejecting valid data?

Almost always because every key was marked required, or because a field that was null in the sample was typed as null rather than nullable. Both are artefacts of inferring from one document, and both need fixing by hand.

How do I get a schema that is actually useful?

Treat the generated output as a first draft. Widen nullable fields to unions, move genuinely optional keys out of required, add format and enum where you know the constraint, and validate it against several real documents rather than the one you generated it from.

Sources

• JSON Schema Specification