Skip to content
ToolBoxGeniehome

JSON Schema Generator

Developer Tools · Added

A schema describes a set of documents; a sample is one member of that set. Inference is therefore guesswork, and the difference between a useful guess and a useless one is being explicit about which guesses were made. This generates a schema in draft 2020-12 or draft-07, merges array elements rather than taking the first as the pattern, detects string formats conservatively, and lists every assumption underneath so you know what to edit.

Paste a representative sample. Arrays are inspected in full, not just their first element.

Goes into the schema's title field

How to use the json schema generator

  1. 1Paste a representative JSON document — one that includes the optional fields you care about.
  2. 2Choose the draft: 2020-12 is current, draft-07 has the widest tool support.
  3. 3Decide whether every property present should be marked required, which is the strictest reading of one sample.
  4. 4Turn on strict objects to forbid properties the sample did not contain.
  5. 5Read the assumptions list before using the output as a contract — it names every place a judgement was made.

Examples

A simple object

Input
{"name": "Ada", "active": true}
Result
An object schema with a string and a boolean, both required

One document cannot show which properties are optional, so all of them are required by default.

Format detection

Input
{"signedUpAt": "2026-03-14T09:30:00Z"}
Result
A string with "format": "date-time"

Detected conservatively: only unambiguous patterns get a format, because a wrong one rejects valid data.

An array with differing objects

Input
[{"a": 1}, {"a": 1, "b": 2}]
Result
Both properties appear, but only "a" is required

Every element is inspected and merged. Taking the first as the pattern would have missed "b" entirely.

About the json schema generator

What a schema is for

The obvious use is validation: checking that a payload arriving at an API boundary is the shape the code expects, and rejecting it with a useful message when it is not. That is worth doing at exactly one place — the edge — because everything inside can then assume the data is well-formed, which removes a great deal of defensive checking from the rest of the codebase.

The less obvious uses are often the more valuable. A schema is machine-readable documentation, so it can generate API reference pages that cannot drift from the implementation. It can drive form generation, since a description of the fields and their constraints is most of what a form needs. It can produce realistic test fixtures. And several tools generate client libraries in various languages directly from it.

It is also a communication artefact between teams. An agreed schema is a contract that can be versioned, reviewed and tested against, which is a considerably better basis for an integration than a sample payload pasted into a chat message — which is, in practice, what a schema is usually replacing.

Editing the generated schema

Treat the output as a first draft rather than a finished artefact. The generator can see structure and it cannot see intent, so everything that matters about business rules has to be added by hand.

The first pass is usually the required arrays: work through them and remove anything genuinely optional. The second is constraints the sample cannot imply — a `minimum` and `maximum` on a numeric field, an `enum` where only certain values are legal, a `pattern` on a string with a defined shape, `minItems` on an array that must not be empty. These are the checks that catch real bad data, and none of them is derivable from one valid document.

Finally, consider structure. A deeply nested schema is hard to read and harder to maintain, and the usual remedy is to pull repeated shapes into `$defs` and reference them with `$ref`. That also makes reuse possible across several schemas that share a definition of, say, an address or a monetary amount — which is where a schema stops being a validation detail and starts being part of how a system is described.

Frequently asked questions

Why is every property marked required by default?
Because it is the strictest reading of the evidence, and because loosening a schema is a one-line edit while discovering a missing field in production is not. A single document genuinely cannot distinguish a required property from an optional one that happened to be present. Marking them all required means the schema will reject documents your sample did not cover, which is a visible failure — the alternative silently accepts data your code is not ready for.
How are arrays handled?
Every element is inspected and their schemas merged, rather than the first being taken as the pattern. That matters for real data, where an array of objects often has fields present on some and absent on others: sampling the first element would miss them entirely. Where elements genuinely disagree in type, the result uses `anyOf` rather than picking one, because claiming a single type would be a statement the sample does not support.
Why did my 2.0 become an integer?
Because JavaScript has one numeric type and 2.0 parses as the integer 2 — the trailing zero is gone before any schema logic sees it. JSON Schema distinguishes `integer` from `number`, so a field that happens to hold a whole value in your sample gets typed as an integer even if it can hold fractions. The generator flags this in the assumptions when it spots the pattern in the source text, and widening the type to `number` is the fix.
Which draft should I choose?
2020-12 if your validator supports it, since it is the current specification and what new tooling targets. Draft-07 if you need the widest compatibility — it is still the most broadly implemented version, particularly in older libraries and in tools that embed schema validation rather than depending on a library. The two differ mostly in how they handle references and array item types; for the schemas this generates, the practical difference is the `$schema` URI at the top.
How is this different from generating TypeScript types?
They describe the same shape for different purposes. A TypeScript type is checked at compile time and vanishes at runtime, so it protects the code you write and does nothing about the data that arrives. A JSON Schema is a runtime contract — it validates real payloads at a boundary, and it can express constraints a type cannot, such as string formats, numeric ranges and required-versus-optional in a way that survives into production. Most projects that care want both.

Related tools