JSON to JSON Schema

JSON Schema describes what a JSON document is allowed to look like — which keys exist, what type each holds, and which are required. Validators like Ajv check payloads against it, OpenAPI embeds it, and code generators consume it. Writing one by hand from a real payload is tedious, so this tool infers it: paste a sample, get a schema that sample already validates against.

The inference walks every element of every array, not just the first record. A field missing from some records is left out of required, a value that is sometimes null widens to a type union, and whole numbers come out as integer while decimals come out as number — the distinctions a schema is actually for.

Which draft does the output follow?

It declares draft 2020-12 in the $schema line. Only the structural keywords are emitted — type, properties, required, items, anyOf — and those have been stable since draft-04, so the schema works with older tooling too; delete the $schema line if your validator predates the declaration.

Why is a field missing from required?

Because it was absent from at least one record in the sample. A schema that required it would reject some of the very data it was inferred from, which is the failure mode of generators that only read the first array element.

Why does an always-null field accept any type?

A null sample carries no type information, so there is nothing to infer — the schema leaves that field open rather than pretending the type is known. Add one real value to the sample and the field gets a proper type.

Are string lengths and numeric ranges included?

No. Constraints the sample never exercises — minLength, minimum, pattern, format — are left open instead of guessed, because a guess would reject valid data. Tighten those by hand once the structure is in place.