Generating a JSON Schema From Sample Data — What "Required" Actually Means

Generate a schema from a single JSON example and every field that's present becomes required — the generator has no way to know that middleName was only present on this one record because this particular person happens to have one. Paste a second sample where middleName is missing, and it correctly drops out of required and becomes optional instead. That's the entire trick: required/optional is inferred from what actually varies across the samples you provide, not guessed from a single shape.

// sample 1
{ "id": 1, "name": "Ada", "middleName": "Lovelace" }

// sample 2
{ "id": 2, "name": "Bob" }

↓ (merged schema)
{
  "type": "object",
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "middleName": { "type": "string" }
  },
  "required": ["id", "name"]
}

Same engine as Living Types, different output format

This tool and Living Types share the same multi-sample inference underneath — merge N real payloads, and optionality, nullability, and type unions all come from observed variation across them. The difference is what comes out the other end: this page renders a plain draft-07 JSON Schema, Living Types renders that same inferred shape as a TypeScript type and a Zod validator, and can save it as a snapshot to diff against later. If what you actually need is a type definition and runtime validation rather than a schema document, that's the one to use instead.

What the validator here checks — and what it doesn't

The validator supports a practical subset of draft-07: type/integer, properties + required, items, enum, minLength/maxLength, pattern, minimum/maximum, and additionalProperties: false. It does not implement $ref, oneOf/allOf/not, or format keywords like format: "date-time". Full draft-07 conformance needs validating against the meta-schema itself, which is a meaningfully bigger project than a quick paste-and-check tool — if you need full spec coverage, a dedicated library like ajv is the right call, not this page.

Additional properties are allowed by default

Unless the schema explicitly sets additionalProperties: false, extra fields on the data that aren't in properties are silently allowed — that's the JSON Schema spec's default, not a shortcut this validator takes. If you want to catch a typo'd field name (usrename instead of username) as an error rather than an ignored extra property, you have to add additionalProperties: false yourself.