JSON Schema Generator

Paste a JSON example and get a JSON Schema (Draft 2020-12) instantly.

Make all parsed properties requiredAllow additionalProperties in schema

JSON input

JSON Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "age": {
      "type": "integer"
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "tags": {
      "type": "array",
      "items": {
        "oneOf": [
          {
            "type": "string"
          },
          {
            "type": "string"
          }
        ]
      }
    },
    "address": {
      "type": "object",
      "properties": {
        "street": {
          "type": "string"
        },
        "city": {
          "type": "string"
        },
        "active": {
          "type": "boolean"
        }
      },
      "required": [
        "street",
        "city",
        "active"
      ],
      "additionalProperties": false
    }
  },
  "title": "Root",
  "required": [
    "name",
    "age",
    "email",
    "tags",
    "address"
  ],
  "additionalProperties": false
}

Generate JSON Schema from example JSON

This tool analyzes your JSON and infers a Draft 2020-12 JSON Schema — including types, required fields, nested objects, arrays, and common string formats (email, URI, date). It's a starting point; review and adjust the schema for your API or validation needs. To explore the structure visually, use JSON Tree Viewer. To format raw JSON, try JSON Formatter.

Built and maintained by Meet Shah · Last updated 2 August 2026

What this tool is used for

Producing a first-draft schema from a real API response instead of writing one from scratch.
Generating a schema to use as a contract test against a service you do not control.
Documenting the shape of a payload you have inherited with no specification.
Creating a starting point you then tighten by hand with formats and constraints.
Comparing two versions of a response by generating a schema for each.

Frequently Asked Questions

What does a generated schema actually give me?: A machine-readable CONTRACT that validators, form builders, editors and documentation tools all consume. Its value is enforcement across systems — which is exactly what an ad-hoc example document cannot provide.
Which draft should I target?: 2020-12 is current and is what OpenAPI 3.1 uses. Draft-07 remains the most widely implemented in older tooling. They differ materially — $ref handling and array keywords changed — so the draft is not a detail.
Can required be inferred from a sample?: No, and this is the main limitation. A field present in your sample may be optional and one absent may be required. Generation produces a plausible skeleton; the constraints are a human decision.
How do I stop unknown properties?: additionalProperties: false, which is NOT the default — by default any extra property is accepted. For configuration files that default means a typo'd key is silently ignored rather than reported.
What about formats like email or date?: The format keyword is annotation-only by default and many validators do not enforce it. If you need it checked, enable format assertion explicitly or add an explicit pattern — assuming it validates is a common mistake.

Common errors and gotchas

Shipping the generated schema unedited. It describes one example, not the range the API can actually return.
Assuming every present field is required. A single sample cannot tell you what is optional.
Losing array element variety, since the shape is usually inferred from the first element only.
Overlooking that a `null` in the sample becomes a null type, which is rarely what the API means.
Expecting formats like date-time or email to be inferred. They look like plain strings to a generator.