Generate JSON Schema from sample JSON

Use samples that show variation

One perfect object makes a weak schema. Use several records that show optional fields, present nulls, nested arrays, date-like strings, and values that might later become enums.

The fixture below intentionally includes region as a string, region as null, one missing region, one present coupon, and two records without coupon. That gives the inference pass something real to observe instead of pretending every property is always present.

[
  {"id":"evt_1","type":"signup","region":"EU","createdAt":"2026-09-04T12:00:00Z","user":{"email":"lin@example.test","plan":"pro"}},
  {"id":"evt_2","type":"paid","region":null,"createdAt":"2026-09-04T12:04:30Z","user":{"email":"lin@example.test","plan":"pro"},"coupon":"LAUNCH"},
  {"id":"evt_3","type":"trial","createdAt":"2026-09-04T12:07:00Z","user":{"email":"mara@example.test","plan":"free"}}
]

Generate and read the schema

Open the source, choose View schema, then select JSON Schema. The schema tab is intentionally separate from editing the source, so you can inspect the generated output before copying or downloading it.

The emitted document uses $schema: "https://json-schema.org/draft/2020-12/schema". Object properties are inferred from observed fields. A field observed on every object at the same level can become required; a field missing from some records stays optional in the inferred shape.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "id": {
        "type": "string",
        "x-json-all-in-one-path": "$[].id",
        "x-json-all-in-one-presence-count": 3
      },
      "region": {
        "anyOf": [{ "type": "string" }, { "type": "null" }],
        "x-json-all-in-one-path": "$[].region",
        "x-json-all-in-one-presence-count": 2,
        "x-json-all-in-one-null-count": 1
      }
    },
    "required": ["createdAt", "id", "type", "user"]
  },
  "x-json-all-in-one-path": "$",
  "x-json-all-in-one-presence-count": 1
}

• Generate TypeScript after reviewing the schema

What can be inferred

The generator can infer broad JSON types such as object, array, string, integer, number, boolean, and null. It can also surface observed string hints such as date-time, email, or URI, and it records useful counts in x-json-all-in-one-* fields.

Those hints are evidence from the sample, not business truth. A value that looks like an ISO timestamp is not proof that every future value will be a timestamp. Two observed plan names are not proof that the plan list is complete.

Inference is not validation

Generating a schema and validating data against an independent schema are different tasks. Treat this workflow as inference from samples, then validate with the validator or application runtime your team already trusts.

After export, review the schema in the toolchain that will consume it. Some teams will remove observation metadata, tighten formats, add descriptions, or split one generated schema into multiple domain models.

Review checklist

• Are required fields truly required, or merely present in this sample?
• Are null and missing treated differently where your API cares?
• Are numbers safe for the consuming language or should identifiers be strings?
• Are date, email, and URI hints correct for production data?
• Should generated enum candidates remain suggestions instead of final constraints?

Next step

Use the schema as a review surface before generating code. If your next task is model generation, continue with JSON to TypeScript. If your next task is reviewing a changed payload, use Compare JSON files.