JSON Schema Generator: Turn Any JSON Example into a Production-Ready Schema in Seconds
Learn how the free JSON Schema Generator from Online Tools Forge infers types, required fields, and string formats from any JSON example across Draft 2020-12, 2019-09, and Draft-07.
Table of Contents
JSON has become the lingua franca of modern software β APIs, configuration files, webhooks, event streams, and data pipelines all speak it. But raw JSON tells you nothing about the contract behind it. Which fields are guaranteed to exist? Is that ID a string or a number? Must every record include an email address? JSON Schema answers these questions with a formal, machine-readable description of your data, and it has become the de facto standard for validating JSON across virtually every programming language.
The problem is that writing schemas by hand is tedious, error-prone, and easy to put off. That is exactly what our JSON Schema Generator solves: paste any JSON example, and it instantly produces a valid schema with inferred types, required fields, and detected string formats β in Draft 2020-12, 2019-09, or Draft-07. Everything runs client-side in your browser, so your data never touches a server.
In this guide we will walk through why schema inference matters, the tool's key features, a step-by-step workflow, the practical differences between the three supported drafts, and real-world use cases from API contracts to code generation.
Why Use a JSON Schema Generator?
- Eliminate hand-written boilerplate. A realistic schema for a nested API payload can run to dozens of lines of repetitive type, properties, and required declarations. Inference writes all of that for you in one pass, leaving you free to refine rather than transcribe.
- Catch contract drift early. When a backend silently changes a field from string to number, downstream consumers break in confusing ways. A generated schema pinned to a known-good example becomes a tripwire that flags the change at validation time.
- Standardize API contracts. Schemas give frontend, backend, QA, and documentation teams a single source of truth about payload shape β no more arguing over wiki pages or stale sample files.
- Detect formats automatically. Hand-writing "format": "email" or "format": "uuid" annotations is easy to forget. Automatic detection of date-time, date, time, email, uuid, uri, and ipv4 values adds semantic precision you would otherwise skip.
- Get required fields right. Guessing which fields are mandatory from a single sample is unreliable. Merging multiple array items and intersecting the fields present in every object gives you an evidence-based required list.
- Keep sensitive data private. Because generation happens entirely in your browser, production payloads, tokens, and personally identifiable information never leave your machine β a big advantage over server-based converters.
Key Features
| Feature | What it does |
|---|---|
| Three schema dialects | Generates Draft 2020-12, 2019-09, or Draft-07 output with the correct $schema URI set automatically |
| Automatic type inference | Detects string, number, integer, boolean, object, array, and null values |
| Smart string format detection | Recognizes date-time, date, time, email, uuid, uri, and ipv4 patterns (toggleable via "Detect formats") |
| Array item merging | Merges the schemas of all array items β union of properties, intersection of required fields β so mixed arrays yield one unified item schema |
| "All fields required" option | Marks every property as required, instead of only those present in every merged object |
| additionalProperties toggle | Controls whether extra, undeclared fields are allowed (defaults to false for strict contracts) |
| Instant client-side generation | No server round-trip, no uploads, no waiting β the schema appears as you work |
A few of these deserve a closer look:
- Array item merging is the heart of good inference. Real-world arrays are messy: one item has a nickname field, another doesn't; one has a nullable score. The generator inspects every item, unions their properties into a single item schema, and marks only the fields found in every item as required β producing a schema that reflects the whole dataset, not just the first element.
- Format detection is opt-out, not opt-in. The "Detect formats" toggle is on by default, but you can disable it when you prefer plain "type": "string" without semantic annotations β useful when values merely resemble a format but should not be constrained by one.
- Strict by default. With additionalProperties defaulting to false, generated schemas reject unknown fields out of the box. Flip the toggle when you need forward-compatible contracts that tolerate new fields.
How to Use the JSON Schema Generator
- Paste your JSON example. Drop a representative sample β a single object or an array of objects β into the input panel. Messy, real-world data actually produces better schemas than idealized samples.
- Choose your draft. Select Draft 2020-12, 2019-09, or Draft-07 from the dialect picker. The generator sets the matching $schema URI for you.
- Set your options. Keep "Detect formats" enabled for semantic annotations, decide whether "All fields required" should apply, and confirm the additionalProperties behavior fits your contract.
- Generate. Click generate and the schema is built instantly in your browser β types inferred, required lists computed, formats annotated.
- Copy and integrate. Copy the output into your validation layer, OpenAPI document, or CI pipeline, then tighten it further with enums, patterns, or bounds as your domain demands.
Understanding JSON Schema Drafts
JSON Schema has evolved through several drafts, and choosing the right one affects which keywords and validators you can use.
Draft 2020-12 is the current standard and the best default for new projects. It refines vocabulary organization, dynamic references, and array keywords (prefixItems replaces the tuple form of items). OpenAPI 3.1 aligns fully with Draft 2020-12, making it the natural choice for modern API specifications.
Draft 2019-09 introduced recursive references and vocabularies and remains well supported. Choose it when your validation stack predates 2020-12 support but you still want relatively modern semantics.
Draft-07 is the most widely implemented dialect in the wild β countless validators, code generators, and legacy pipelines target it. If you are feeding schemas into older tooling or an OpenAPI 3.0 workflow, Draft-07 is the safe pick.
Whichever draft you choose, the generator applies the same inference logic:
- Type inference maps each JSON value to its schema type: quoted values become string, whole numbers become integer, decimals become number, and true/false become boolean. Nested objects and arrays recurse, and null values produce the null type.
- Required fields are computed from evidence. For a single object, every present field is required. When merging array items, only fields appearing in every object survive the intersection β unless you enable "All fields required."
- String format detection matches values against well-known patterns: RFC-style timestamps become date-time, date, or time; addresses become email; canonical hex IDs become uuid; links become uri; and dotted quads become ipv4.
Here is a small example input:
{
"id": "9f1c2a4e-6b3d-4f5a-9e2c-1a8d7f0b3c4e",
"email": "[email protected]",
"createdAt": "2026-08-19T09:30:00Z",
"age": 36,
"active": true,
"tags": ["admin", "editor"]
}
And the schema generated with Draft 2020-12, format detection on, and the default strict settings:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"id": { "type": "string", "format": "uuid" },
"email": { "type": "string", "format": "email" },
"createdAt": { "type": "string", "format": "date-time" },
"age": { "type": "integer" },
"active": { "type": "boolean" },
"tags": {
"type": "array",
"items": { "type": "string" }
}
},
"required": ["id", "email", "createdAt", "age", "active", "tags"],
"additionalProperties": false
}
Every type, format, and required entry was inferred β no hand-typing involved.
Practical Use Cases
API Contract Validation
Capture a real response from your API, generate a schema, and wire it into your test suite or gateway. Regressions like a missing field, a type flip, or an unexpected extra property fail validation immediately instead of surfacing as mysterious client bugs weeks later.
OpenAPI Documentation
OpenAPI 3.1 components are JSON Schema. Instead of hand-authoring component schemas for every endpoint, generate them from example payloads and paste them into your spec. Your documentation stays accurate because it starts from data that actually flows through the system.
Configuration File Validation
Tools like ajv, Python's jsonschema, and many IDE extensions can validate config files against a schema. Generate a schema from a known-good configuration, commit it to the repository, and catch typos, wrong types, and missing keys at load time β or even in the editor as you type.
Code Generation and Type Safety
Feed a generated schema into code generators and validation libraries β TypeScript types, Pydantic-style models, Go structs, or ajv validators β to get compile-time and runtime safety from a single artifact. Because the schema started from real data, the generated code matches reality rather than someone's memory of the API.
Best Practices
- Start from representative data. The more realistic and varied your sample (especially arrays with diverse items), the more accurate the inferred required fields and types will be.
- Treat the output as a first draft. Inference captures structure, not business rules. Add enums, patterns, minimum/maximum bounds, and descriptions to encode domain constraints.
- Be deliberate about additionalProperties. Strict (false) contracts catch unexpected fields early; permissive (true) contracts survive upstream additions. Choose based on how much you trust the producer.
- Verify format annotations. A string that looks like a UUID but isn't one will cause false rejections. Disable format detection or strip specific formats when they over-constrain the data.
- Match the draft to your tooling. Confirm your validator or OpenAPI version supports the dialect you pick β there is nothing worse than a perfect schema rejected by an old parser.
- Version your schemas alongside your API. When payloads evolve, regenerate and diff the schema so contract changes are reviewed like any other code change.
Start Generating Schemas Today
Stop transcribing properties blocks by hand. Open the JSON Schema Generator, paste any JSON example, and get a clean, standards-compliant schema β with inferred types, evidence-based required fields, and automatic format detection β in seconds, entirely in your browser. Your future self debugging a payload mismatch will thank you.
Related Tools You Might Like
- /en/tools/json-schema-validator β Validate any JSON document against a schema to confirm it matches your contract before it reaches production.
- /en/tools/json-to-typescript β Convert JSON data into TypeScript interfaces for compile-time type safety in frontend and Node.js projects.
- /en/tools/json-formatter β Pretty-print, minify, and sanity-check raw JSON so your input is clean before you generate a schema from it.
Happy schema building!