JSON Schema Generator

Generate a draft 2020-12 JSON Schema from a sample, with required fields inferred across every record rather than assumed.

Generation happens entirely in your browser. The schema is structurally correct but semantically empty — formats, enums and constraints are yours to add.

What It Does

Paste a JSON sample and get a schema that describes it, ready to validate future data against. The part that carries the value is the required list. A schema generated from a single object marks every field required, and then rejects valid data as soon as an optional field is genuinely absent — which is the most common way a hand-rolled schema goes wrong. This one merges every element of an array before deciding, so a key present in some records and not others is described but not required. Beyond that it distinguishes integer from number where the sample allows, closes objects by default so unexpected keys are caught, and emits the $schema declaration explicitly because validators behave differently across drafts and guessing is unreliable.

When to Use It

  • You are integrating a third-party API and want runtime validation so a change in its response surfaces as a clear error.
  • An internal service contract needs writing down and you have example payloads rather than a specification.
  • You want to document a webhook body in a form both people and machines can read.
  • A config file format needs validating in CI before a bad file reaches production.
  • You are writing tests and want to assert that a response matches a shape rather than exact values.

Worked Examples

[{"id":1,"title":"First","pinned":true},{"id":2,"title":"Second"}]

The required-field case. Because pinned is absent from the second record it is described but left out of required, while id and title appear everywhere and are required.

{"count":42,"ratio":0.75,"label":"weekly"}

Shows integer versus number. The count has no fractional part so it is typed integer, while the ratio is typed number — a real constraint that a naive generator would flatten to one type.

{"user":{"id":1,"email":"[email protected]"},"tags":["a","b"]}

Nesting and arrays. The user becomes a nested object schema with its own required list, and tags becomes an array with a typed items schema. Adding format: email to that field by hand is the natural next step.

Features

Draft 2020-12 output with an explicit $schema declaration
Required fields inferred across every array element
Integer distinguished from number where the sample allows
Nested objects and arrays described recursively
additionalProperties toggle for strict or permissive validation
Union types emitted where a field varies
Optional example embedded in the schema
Custom schema title
Warning when a single sample cannot reveal optionality
Runs entirely in your browser

How to Use

1. Paste your JSON — a full array of records gives a far more accurate required list. 2. Set a title for the schema. 3. The schema appears immediately below. 4. Decide whether additionalProperties should stay false for strict validation. 5. Copy it, then add formats, enums and descriptions by hand where you know them.

Common Mistakes

  • Generating from a single object. Every field comes back required, and the schema then rejects valid data the first time an optional field is missing.
  • Leaving additionalProperties false on a third-party API. It catches typos beautifully but breaks the moment the provider legitimately adds a field you do not control.
  • Trusting the integer inference. It comes from the sample, so a value that happened to be whole will reject a decimal later — widen it where the field genuinely allows one.
  • Shipping the schema without formats or constraints. The structure is correct but says nothing about what a valid email, date or identifier looks like.
  • Omitting the $schema declaration when hand-editing. Validators differ across drafts, and without it some will guess and behave unexpectedly.

Frequently Asked Questions

Explore related topics

#JSON