JSON Schema Generator

Paste one or several JSON samples and the generator infers a JSON Schema you can use to validate new payloads. Detects types, marks fields as required when they appear in every sample, infers enums when values are drawn from a small closed set, and produces output conforming to JSON Schema draft 2020-12.

How to generate a JSON Schema

  1. 1

    Paste sample documents

    One or several real payloads: the more variety, the more accurate the inferred schema.

  2. 2

    Pick the draft

    Draft 2020-12 (current), draft 07 (widely supported), or draft 04 (legacy OpenAPI).

  3. 3

    Tune inference

    Toggle enum inference, required fields strategy (intersection vs union), and whether to mark all fields `required` when only one sample is given.

  4. 4

    Generate

    The schema is emitted with `$schema`, `title`, `type`, `properties`, and nested `$ref`s for repeated sub-objects.

What inference does well

  • Types: string, number, integer, boolean, null, array, object.
  • Nullability: a field that is null in one sample and a string in another becomes ["string", "null"].
  • Array items: homogeneous arrays produce a single items schema; heterogeneous arrays produce prefixItems.
  • Enums: if all observed values are from a small set (configurable, default 10 distinct values), emits an enum.
  • Required: with multiple samples, the intersection of keys becomes required; with one sample, all keys are required unless you opt out.
  • Formats: strings matching ISO-8601 dates, emails or URIs get an inferred format.

What inference cannot know

  • Intent vs example: a sample age: 25 infers type: integer, but cannot know you also accept null. Pass multiple samples that cover edge cases.
  • Constraints: minLength, maximum, pattern, you have to add these by hand. Inference does not guess limits from samples.
  • Business logic: “exactly one of these three fields must be set” requires oneOf, not inferrable.
  • References: the generator emits a flat schema. If you want to factor repeated shapes into $defs, do that after generation.

Example output

From a single sample:

{ "name": "Alice", "age": 30, "tags": ["admin", "user"] }

The inferred schema (draft 2020-12):

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer" },
    "tags": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["name", "age", "tags"]
}

Common mistakes

  • Inferring from one sample. The schema will over-fit, every field becomes required, no null tolerance. Always feed at least 5-10 varied samples.
  • Using integer when you meant number. If any sample has a decimal, the inferred type becomes number; if all are whole, it becomes integer. For fields that could be either, include a decimal sample.
  • Forgetting optional fields. A field present in 4 of 5 samples but missing from 1 becomes optional, intended. If all 5 samples happen to include it, the schema will mark it required even though it is actually optional in your API.

Frequently Asked Questions

The more the merrier, but 5-10 varied samples typically produce a reasonable schema. With one sample, every field becomes required and nullability cannot be inferred, always provide multiple variants if you can.

Draft 2020-12 by default. Draft 07 and 04 are available for OpenAPI 3.0 compatibility (which uses a draft 05/07 subset).

No. Inferring sensible constraints from samples would over-fit the schema. Add minLength, maximum, pattern etc. manually after generation based on your business rules.

Yes. If you paste a JSON array, the generator treats each element as a separate sample and produces a schema describing an individual element, not the outer array. Toggle “treat as array container” if you want the outer array’s shape instead.

Related Tools

Tool available in other languages