JSON Schema Generator from JSON

Infer a JSON Schema (draft 2020-12) from sample JSON: types, required keys, nested objects, array items and formats like date-time. Runs in your browser.

Loading tool…

Worked examples

  • A user object with nested data and formats

    Strings that look like UUIDs, emails, dates and timestamps get a format; nested objects and the array's item type are described recursively.

  • An array of records that differ from each other

    The array's items are merged: keys present in every record are required, the rest are optional, null plus a string becomes a type list, and 9.5 with 7 widens to number.

  • Mixed array items, strict objects

    A mixed array yields a union of item types, an empty array gives no item constraint at all, and strict mode forbids extra properties.

What this does

Paste a sample JSON document and get a JSON Schema for it, written for draft 2020-12, the current version of the specification. The generated schema describes what your sample contains: each value's type, which keys are required, how objects nest, and what array items look like. It is a fast starting point for API contracts, config validation and editor autocomplete, which you then tighten by hand.

How it works

The tool parses the sample and records what it sees at every position, then writes the schema from those observations.

  1. Types. Each value is typed as string, integer, number, boolean, null, object or array. If both integers and non-integers appear at one position, they merge into number, because every integer is also a valid number. Any other mix becomes a type list, such as ["string", "null"].
  2. Objects. Each key becomes an entry in properties. A key is listed in required when it was present in every object seen at that position. With a single object that means all keys.
  3. Arrays. Every element of an array is merged into one items schema, so [1, "two", null] gives a union of item types, and an array of objects gives one object schema where keys that appear in only some of them are optional. An empty array gets no items keyword at all, which means anything is allowed.
  4. Formats. When a string matches a known shape, the schema adds a format: date-time (RFC 3339, with a T), date, email, uuid, uri or ipv4. A format is only added when every string at that position matches the same one, and dates are checked against the calendar, so 2026-02-30 is not a date.

Options let you drop required, turn format detection off, add additionalProperties: false to every object, and set a title.

What it cannot infer

A sample shows what is, not what is allowed. The schema will not contain minimum or maximum values, string lengths, regular expression patterns, enums, minItems, uniqueItems, or descriptions. A key that happened to appear in your one sample is marked required even if it is optional in practice, so feed it an array with several representative records, or turn off the required option and add it by hand.

Two further limits are worth knowing. JSON cannot distinguish 1.0 from 1, so a whole number is always typed integer. And when objects at one position have different shapes (a union of record kinds), the tool merges them into one object schema with optional keys instead of writing oneOf or anyOf, which is looser than the data really is.

The format gotcha

In draft 2020-12, format is an annotation by default, not an assertion. A validator such as Ajv will ignore "format": "email" unless you enable format checking, for example with the ajv-formats package. If you rely on the schema to reject bad emails or dates, configure the validator accordingly.

When to use it

  • Bootstrapping a schema for an API response to commit next to your tests.
  • Adding editor validation and autocomplete to a JSON or YAML config file.
  • Documenting an undocumented payload by turning a captured sample into a readable structure.

Run the result through the JSON Schema Validator with your sample to confirm it passes, then edit in the constraints the sample could not tell us.

Frequently asked questions

Which JSON Schema version does it generate?
Draft 2020-12, declared with the $schema keyword https://json-schema.org/draft/2020-12/schema. It only uses long-standing keywords (type, properties, required, items, format, additionalProperties), and the same keywords exist in draft 2019-09 and draft-07, so for a validator that only knows an older draft, change or remove the $schema line.
How does it decide which keys are required?
A key is required when it appears in every object the tool saw at that position. With one sample object that means every key; with an array of objects it means only the keys present in all of them. Untick the required option if you want a permissive schema with no required list.
What cannot be inferred from one sample?
Anything that is a rule rather than an observation: minimum and maximum, string length and pattern, enum lists, uniqueness, minItems, and whether a key that happened to be present is really mandatory. The tool also cannot tell 1.0 from 1, because JSON parsing erases that difference, so a whole-number value is typed integer.
Does the format keyword validate emails and dates?
Only if your validator is configured to check formats. In draft 2020-12, format is an annotation by default, and validators such as Ajv need the ajv-formats plugin or an equivalent option to assert it. Detected formats are date-time, date, email, uuid, uri and ipv4, and a format is added only when every string seen at that position matches the same one.