Online JSON Schema Generator: Auto-Generate Schema from JSON Data

What Is JSON Schema

JSON Schema is a standard for describing and validating JSON data structures. It defines the properties, types, constraints, and defaults of JSON objects. Feed your sample data into our JSON Schema Generator to produce a ready-to-use schema automatically.

Example JSON Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0 },
    "email": { "type": "string", "format": "email" },
    "tags": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["name", "email"]
}

Why You Need JSON Schema

1. API documentation: Auto-generate API request/response structure docs (the JSON Schema editor validates as you write, right in the browser)
2. Data validation: Validate JSON data correctness at runtime
3. Form generation: Auto-generate form UI from Schema
4. Mock data: Generate test data based on Schema
5. Type safety: Generate TypeScript type definitions from Schema
6. Config validation: Verify config file format is correct

JSON Schema Core Keywords

How to Use an Online Tool

Using ToolVault's JSON Schema Generator:

1. Paste a JSON object example
2. Toggle options as needed: enable Infer format so sample values like emails, date-times, URIs, UUIDs, and IP addresses automatically produce "format" annotations; switch Spec version to stamp $schema as draft-07 or 2020-12
3. Click Generate — the tool analyzes the structure (nested objects, array elements, nullable fields all handled)
4. One-click copy the schema, then hand-tighten required / enum / pattern to match your contract

Auto-Generate from JSON Example

Input

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "isActive": true,
  "tags": ["developer", "admin"],
  "address": { "city": "Shanghai", "zip": "200000" }
}

Output Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string" },
    "email": { "type": "string" },
    "isActive": { "type": "boolean" },
    "tags": { "type": "array", "items": { "type": "string" } },
    "address": {
      "type": "object",
      "properties": {
        "city": { "type": "string" },
        "zip": { "type": "string" }
      }
    }
  }
}

JSON Schema Validation in Code

JavaScript (Ajv)

const Ajv = require('ajv');
const ajv = new Ajv();

const schema = {
  type: 'object',
  properties: {
    name: { type: 'string', minLength: 1 },
    age: { type: 'integer', minimum: 0 }
  },
  required: ['name']
};

const validate = ajv.compile(schema);
const valid = validate({ name: 'Alice', age: 28 });
console.log(valid); // true

Python

from jsonschema import validate, ValidationError

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "minLength": 1},
        "age": {"type": "integer", "minimum": 0}
    },
    "required": ["name"]
}

try:
    validate(instance={"name": "Alice", "age": 28}, schema=schema)
    print("Validation passed")
except ValidationError as e:
    print(f"Validation failed: {e.message}")

Inference from samples: what one document can and cannot tell

A schema generated from a single sample is a description, not a constraint — it records what was seen (every field required, types as-observed, no bounds) and misses everything about variation (optional fields absent that day, string formats, numeric ranges, enums where the sample had one value). The generation disciplines: feed multiple samples (union of observed shapes — three diverse samples beat one perfect one), treat inference output as a draft (a human hour tightening types, adding bounds, marking truly-optional fields turns a description into a contract), and prefer source-of-truth generation (TypeScript types, OpenAPI specs, database DDL to JSON Schema) when any exists — inferring from data what the code already knows is archaeology. The one-sample schema deployed as validation is the false-confidence machine: it passes today's data because it was built from today's data.

Draft versions: the generator setting that changes output

The draft selector (draft-04 / draft-07 / 2019-09 / 2020-12) is not cosmetic: exclusiveMinimum is boolean in draft-04, numeric in draft-07 and later; definitions becomes dollar-defs in 2019-09; and dollar-ref semantics shifted (2019-09 separates ref from adjacent keywords — draft-07 ignores siblings, later drafts process them). Generating draft-04 output for a modern validator produces schemas that silently validate wrong or fail to load. The choice rule: match the validator you will run (Ajv 8 defaults to 2020-12; Python jsonschema historically defaults draft-07), and pin the draft in tooling config rather than accepting latest — a draft upgrade is a breaking change to schema semantics, not a minor tool update.

Schema evolution: versioning without breaking consumers

Schemas change; the consumers' code does not update simultaneously. The compatibility rules worth memorizing: adding optional fields is backward-compatible (old data validates against new schema) and forward-compatible only if additionalProperties permits unknowns (the most overlooked flag in production); narrowing a type (string to string-plus-enum) is backward-compatible but breaks forward; removing or renaming breaks both directions. The operational pattern: treat schema files like APIs — version them, run compatibility CI (old samples validate against the new schema on every change), and deprecate fields before removing them across release boundaries. Discovering incompatibility when a consumer rejects a Tuesday's data is the failure mode the whole discipline exists to prevent.

Formats the generator can hint (and what still needs humans)

With Infer format on, sample strings that look like emails, URIs, UUIDs, IPv4/IPv6, or date-times can receive a "format" annotation. That is a hint for documentation and for validators that implement those formats — not a guarantee every consumer library honors them the same way. Numeric bounds, enum sets, and required lists almost always need a human pass: one sample cannot know tomorrow's optional field or the closed list of status codes your API allows.

After generation, paste the schema into the JSON Schema Validator with a second, deliberately different payload (missing optional keys, extra properties, boundary numbers). If both the sample and the adversarial payload "just work," the schema is still a description, not a contract.

FAQ

What JSON Schema Versions Are Supported?

Draft 7 (2018-02) and 2020-12 are widely used. Draft 7 remains a practical default for broad library support; pick 2020-12 when your validator and $defs / $ref sibling rules already assume that draft. Pin the draft in tooling config rather than chasing "latest."

Can Schemas and TypeScript Interfaces Be Converted?

Yes. Use typescript-json-schema to generate Schema from TS, or json-schema-to-typescript to generate TS interfaces from Schema. Tools automate this process.

Can JSON Schema Validate Nested Objects?

Yes. JSON Schema natively supports nested object definitions using recursive properties. The $ref keyword references defined sub-schemas to avoid duplication.

Triage notes

"The innate limits of single-sample inference" sits after the tutorial body because it is the real boundary of generation: a single-sample schema is a description, not a constraint — shipping it directly is a gate built from today's data to stop today's data, a false-confidence machine that passes every test. The generation discipline is correspondingly concrete: three diverse samples beat one perfect sample, and where a real source of truth exists (TypeScript, OpenAPI, DDL), generate from the source instead of doing data archaeology. The draft section lists version differences as breaking changes (exclusiveMinimum going from boolean to numeric, definitions renamed to $defs) and concludes: lock the version in toolchain config, don't chase the latest. The acceptance bar is just as blunt — if both examples and adversarial payloads sail through, the schema is still a description, not yet a contract.

This article is brought to you by ToolVault. More free local-first tools at the homepage.