Free JSON Schema Generator

What JSON Schema Is For

JSON Schema is a declarative way to describe what a JSON document should look like: what properties it has, what types those properties hold, what's required vs optional, and what values are valid. It's the JSON-world equivalent of XSD for XML or a database table definition. The official project lives at json-schema.org.

Where you'll meet it in the wild:

• API contracts. OpenAPI 3.1 (Feb 2021 release) embeds JSON Schema directly: every request body and response body in a modern API spec is described with a JSON Schema fragment.
• IDE autocomplete and validation. VS Code's settings.json, your project's package.json and tsconfig.json, GitHub Actions workflow.yml files all autocomplete and lint against published JSON Schemas.
• Server-side validation. Express / Fastify / Spring / Flask / FastAPI / Echo all integrate with JSON Schema validators (AJV, jsonschema, fastjsonschema) to reject malformed request bodies before they hit business logic.
• Code generation. Tools like quicktype, json-schema-to-typescript, and datamodel-code-generator turn a schema into Go structs, TypeScript types, Python dataclasses, Java POJOs, etc., providing language-agnostic types from a single source.
• Documentation. A schema doubles as machine-readable docs for any JSON-shaped data you publish.

The Drafts You'll See in the Wild

JSON Schema's specification has been published as a series of drafts. The current stable draft is 2020-12 (per the official spec page: "The current version is 2020-12"). The drafts you might encounter:

• Draft 4, old but still in use; OpenAPI 3.0 used an extended subset of the JSON Schema Specification Wright Draft 00 (sometimes informally called Draft 5), which is close to but not identical to Draft 4.
• Draft 6, Draft 7, Draft 7 (2018) was the dominant production draft for years and is still very common in legacy tooling.
• Draft 2019-09, first draft to use the year-month identifier convention; introduced $defs alongside the legacy definitions keyword.
• Draft 2020-12, the current stable draft and what this generator emits. Aligned with OpenAPI 3.1.

When in doubt, choose the draft that matches your validator. AJV (the most popular JavaScript validator) supports Drafts 04, 06, 07, 2019-09, and 2020-12 with explicit opt-in. jsonschema in Python does the same. If you don't know what your downstream consumer wants, 2020-12 is a safe default for new work.

The Built-in Types

JSON Schema describes seven base types corresponding to JSON's value kinds:

Composition keywords let you mix-and-match: oneOf (exactly one), anyOf (at least one), allOf (every one), not (the inverse). Plus enum for a finite list of allowed values and const for a single fixed value.

What an Auto-Generated Schema Can and Can't Tell You

Inferring a schema from a single JSON example is powerful but limited. The generator can detect:

• The type of every leaf value (string vs number vs boolean vs array vs object).
• The structure of nested objects and arrays.
• The keys that appear in the example (and mark them required if you opt in).

It cannot detect:

• Optional fields. A key in your example might be optional in the real spec, but a single example can't tell you which. Everything looks required by default.
• Format hints. The string "2024-04-12" looks like a date, but it could also be a free-text label that happens to look date-shaped. Add format: date by hand if the field really is one.
• Validation constraints. Max length, allowed enum values, regex patterns: all need human input.
• Documentation strings. title, description, and examples on each field improve developer experience but require curation.
• Variants. If a field can be either a string or a number depending on context, a single example will pick one and miss the other. Combine multiple examples or use oneOf manually.

Treat the output as a 70%-done starting point. The valuable additions (what fields are actually required, what string formats apply, what value ranges are allowed, what each field means) are the human-curation step.

Two Subtle Pitfalls Worth Knowing

• format is advisory by default in 2020-12. The format-annotation vocabulary marks format: email as a hint, not a hard validation rule, unless your validator explicitly opts into format-assertion. So a string that doesn't match the email regex still passes by default. AJV's strict mode and ajv-formats package add full format validation; check your validator's defaults before relying on format checks for security-critical input.
• additionalProperties: false doesn't cooperate well with allOf. If you compose schemas with allOf for inheritance-style validation, additionalProperties: false on one branch doesn't see properties defined in sibling branches, so legitimate fields fail validation. The fix in Draft 2019-09+ is unevaluatedProperties: false, which is composition-aware.

JSON Schema vs Zod / Joi / Yup vs TypeScript Types

Several technologies overlap with JSON Schema's role; each has a different sweet spot:

• JSON Schema. Declarative JSON, runtime validation, language-agnostic. Wins where API contracts cross language boundaries (e.g. a Go server, a Python data pipeline, and a TypeScript frontend all consuming the same API).
• TypeScript types. Compile-time only. Beautiful for in-process type safety inside a TS codebase but they disappear at runtime, providing no validation of incoming JSON. Tools like json-schema-to-typescript generate types from a schema for the best of both worlds.
• Zod / Joi / Yup. Code-first runtime validation in JavaScript / TypeScript, with TypeScript inference baked in. Single language, but excellent developer experience inside that language. Schemas are JS objects, not portable JSON.
• Pydantic / Marshmallow. The Python equivalents: class-based runtime validation with Python type hints.

If your schema needs to be consumed by multiple languages or by tools (IDEs, OpenAPI tooling, code generators), JSON Schema is the right home. If you're staying inside a single language, the language-native option is usually nicer to write.

Common Use Cases

• Bootstrapping an OpenAPI spec. Paste a real API response, generate the schema, drop it into your components.schemas.
• Generating TypeScript / Go / Python types via quicktype or similar, providing language-agnostic types from a single source.
• Validating untrusted input on a server endpoint with AJV / jsonschema / Pydantic.
• Writing IDE autocomplete for a custom config format. VS Code, JetBrains IDEs, and others read JSON Schemas to power JSON-file autocomplete.
• Documenting the shape of a configuration file for downstream consumers.
• Migrating between data formats. A JSON Schema generated from one source can drive validation, transformation, or documentation downstream.

Common Mistakes

1. Treating the auto-generated schema as the final spec. It's a starting point. Add format hints, mark genuinely-optional fields, add documentation, set value ranges.
2. Missing the $schema declaration. Validators use it to know which draft to apply. Always include it at the top of the schema.
3. Treating required as a per-property attribute. Unlike XSD or Mongoose schemas, JSON Schema's required is an array at the parent object level listing the names of required properties.
4. Forgetting additionalProperties: false when you want strict validation. The default is true, meaning unknown keys are silently allowed.
5. Confusing enum with examples. enum = the list of allowed values (validation). examples = sample values for documentation only (no validation effect).
6. Assuming format is enforced. By default in Draft 2020-12 it's an annotation, not an assertion; your email regex won't run unless you opt in.
7. Inferring optionality from a single example. Every key in your example becomes required by default. Real specs almost always have optional fields; remove them from the required array as part of curation.

More Frequently Asked Questions

Will the schema work with OpenAPI 3.1?

Yes. OpenAPI 3.1 (released February 2021) aligned its schema language fully with JSON Schema Draft 2020-12, which is what this generator emits. Drop the schema into components.schemas in your OpenAPI document and reference it via $ref. Older OpenAPI 3.0 used an earlier subset; you may need to adjust if you're targeting 3.0.

Can I generate types in my language from this schema?

Yes. quicktype generates TypeScript, Go, Python, Java, C#, Swift, Kotlin, Rust, Elm, and others from a JSON Schema. json-schema-to-typescript is a JS-specific alternative. Most modern languages have at least one schema-to-types tool; the generated schema works as input for all of them.

What's the difference between $defs and definitions?

Both are places to put reusable sub-schemas you can $ref elsewhere in the document. definitions is the legacy name, used in Drafts 04, 06, and 07. $defs is the current name, introduced in Draft 2019-09 and continuing in 2020-12. Functionally equivalent, but use $defs for new work.

Is my JSON sent anywhere?

No. Schema generation runs entirely in your browser. The pasted JSON is parsed locally, walked, and emitted as a schema in the output textarea. Nothing is uploaded to a server, logged, or kept after you close the tab. This matters because JSON examples often contain real data (customer records, internal API responses, employee info) that you don't want flowing through a third party.

Why did my array's schema only describe the first element?

Inference from a single example treats arrays as homogeneous: it looks at the first element and assumes the rest match. If your real array can hold different shapes, you'll need to write the items as { "oneOf": [...] } by hand. Or run the generator on each variant separately and combine the schemas.

Should I use a generator at all, or write the schema by hand?

For a small schema you control end-to-end, writing by hand teaches you the spec faster. For a large API response with dozens of nested objects, generating gets you to a draft in seconds and you spend the saved time curating constraints, descriptions, and required arrays. Most working developers do both: generate, then curate.