JSON Schema Generator from Example Data
Generate a JSON Schema from a sample JSON document. Review inferred types, required properties, and format suggestions before adopting it.
JSON Schema Generator workspace
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "GeneratedSchema",
"type": "object",
"properties": {
"id": {
"type": "string",
"format": "uuid"
},
"name": {
"type": "string"
},
"email": {
"type": "string",
"format": "email"
},
"age": {
"type": "integer"
},
"isActive": {
"type": "boolean"
},
"tags": {
"type": "array",
"items": {
"type": "string"
}
},
"createdAt": {
"type": "string",
"format": "date-time"
}
},
"required": [
"id",
"name",
"email",
"age",
"isActive",
"tags",
"createdAt"
],
"additionalProperties": false
}The schema is inferred from a single example, so "required" reflects only the fields present in your sample. If your real data has optional fields, deselect "Mark all properties required" — or hand-edit the resulting array.
Three Draft Versions
Generate against JSON Schema Draft 2020-12 (current), 2019-09, or Draft-07 (legacy — required by OpenAPI 3.0 spec validators).
Smart Format Detection
Strings with email, UUID, ISO date-time, URI, IPv4, or IPv6 shape are tagged with the appropriate "format" field — making the schema usable for inbound-payload validation.
Configurable Output
Toggle: mark all properties as required, deny additional properties, include examples, detect string formats. Pick the right strictness for your validator.
100% Client-Side
Your JSON sample never leaves the browser. All schema inference runs locally via JavaScript. Works offline once loaded.
JSON Schema Generator: Build a Schema From One JSON Example
Generate a JSON Schema from a sample JSON document. Review inferred types, required properties, and format suggestions before adopting it. An example shows what occurred once, not everything a valid document may contain. Optional fields, permitted ranges, string constraints, and array alternatives require explicit review. Select the schema dialect your validator supports and test both accepted and rejected examples.
How to use this JSON Schema generator
- Paste a representative JSON example into the left pane, or click a Sample (user profile, product, error response, order).
- Set a Schema title and choose a draft — Draft 2020-12 for new work, Draft-07 for OpenAPI 3.0 toolchains.
- Toggle the inference options: mark all required, additionalProperties: false, detect string formats, and include examples.
- Read the schema in the right pane — it regenerates the instant you change the JSON or any option.
- Press Copy, then hand-edit the
requiredarray and anyenumor numeric constraints your domain needs.
What is JSON Schema and how does inference work?
JSON Schema is a declarative vocabulary for annotating and validating JSON documents. A schema states the expected type of a value, which properties an object must have via the required array, and what format a string should match. The $schema keyword at the top declares which dialect (draft) the document follows. The current published version is JSON Schema Draft 2020-12, and the underlying JSON syntax it validates is defined by RFC 8259 / ECMA-404.
This generator parses your example with native JSON.parse, then walks the value tree recursively. Each node maps to a type: null → { "type": "null" }, a boolean → boolean, a number → integer or number, a string → string (with an optional detected format), an array → array with inferred items, and an object → objectwith a properties map. Because a single example only shows fields that exist, the tool cannot tell required from optional — so see the nugget below before you trust the output.
"The $schema keyword is used to declare which dialect of JSON Schema the schema was written for."— JSON Schema Draft 2020-12 Core specificationWorked examples: JSON → schema
String with detected format
{ "email": "[email protected]" }
→ { "type": "object", "properties": { "email": { "type": "string", "format": "email" } }, "required": ["email"] }
Heterogeneous array → oneOf
{ "mixed": [1, "two", true] }
→ items becomes { "oneOf": [ { "type": "integer" }, { "type": "string" }, { "type": "boolean" } ] } (variants are deduplicated)
Edge case · whole-number floats & empty arrays
JSON has one number type, so 9.0 and 9 parse identically. The generator uses Number.isInteger(), so a sample of 9.0 infers "integer" — wrong for a price field that can hold decimals. Add a fractional value (9.99) to the sample, or change the type to "number" by hand. Likewise, an empty array [] emits bare { "type": "array" } with no items, since one empty array reveals nothing about its element type.
Detected string formats
When "Detect string formats" is on, these eight patterns are tested in order — the first match wins, and ipv6 is checked before ipv4.
| Format | Example Input | Detection Rule |
|---|---|---|
| [email protected] | Validates against the RFC 5321 / 5322 email format. | |
| uuid | 550e8400-e29b-41d4-a716-446655440000 | Standard 8-4-4-4-12 hex UUID v1-v8 pattern. |
| uri | https://www.toolk.site/path | Detected by leading http:// or https://. |
| date-time | 2026-05-11T14:00:00Z | ISO 8601 timestamp with optional fractional seconds and timezone. |
| date | 2026-05-11 | ISO 8601 calendar date only. |
| time | 14:30:00 | ISO 8601 time-of-day. |
| ipv4 | 192.168.1.1 | Dotted-decimal IPv4 address. |
| ipv6 | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | Eight colon-separated hex groups. |
Detection uses pragmatic regex, not formal grammar parsers — review every detected format before relying on it in a strict-mode validator.
Where a generated schema pays off
| Use Case | Why a Generator Helps |
|---|---|
| OpenAPI spec authoring | Generate component schemas in seconds from real example responses, then paste into your OpenAPI YAML. |
| API request validation | Run the generated schema through Ajv (Node) or jsonschema (Python) to validate inbound payloads. |
| Form generation | Tools like JSON Forms and react-jsonschema-form turn a schema into a UI; start with a real example. |
| Database column types | Infer initial column types when ingesting unfamiliar JSON into a relational store — string vs integer vs boolean. |
| Documentation generation | Schemas feed documentation tools (Redoc, ReDocly, Stoplight) that render reference pages. |
| Type-safe code generation | Pair the schema with json-schema-to-typescript or quicktype to emit TypeScript / Go / Rust types. |
The required-array trap most generators hide
A schema inferred from one example treats every key it sees as mandatory. The walk pushes each observed property into the required array when "Mark all properties required" is on (the default). That is convenient for a first draft, but it means an optional field that happened to be present in your sample will reject every payload that omits it. There is no way for a single example to distinguish "always present" from "present this once."
Two more limits come straight from the inference logic: numeric bounds (minimum, maximum, multipleOf) and enum value sets are never inferred, because one value cannot reveal a range or a fixed set. And a mixed array such as [1, "foo", true] is treated as a heterogeneous list via oneOf, not a positional tuple — if you need tuple semantics, rewrite items as prefixItems in Draft 2020-12 by hand. Treat the output as a high-quality starting point, not a finished contract.
Related JSON & data tools
Validate and beautify the example first
JSON to TypeScriptCompile-time types from the same input
JSON DiffCompare two payloads field by field
JSON to YAML ConverterMove schemas between formats
CSV to JSON ConverterTurn tabular data into JSON to schema-check
YAML ValidatorLint OpenAPI YAML before pasting schemas
XML FormatterTidy XML payloads from legacy APIs
SQL FormatterFormat queries that produce the JSON
Regex TesterBuild custom "pattern" constraints
Base64 EncoderEncode binary fields embedded in JSON
Guide: JSON ValidationHow JSON parsing and validation work
Guide: JSON vs YAML vs XMLPick the right data format
All ToolsBrowse the full Toolk toolbox
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
Which JSON Schema draft should I target?
Draft 2020-12 for new work and for OpenAPI 3.1, which adopted it wholesale. Choose Draft-07 only when a legacy OpenAPI 3.0 toolchain demands it — that draft lacks $defs and unevaluatedProperties. This generator also emits 2019-09 when you need the intermediate revision. Check which drafts your validator supports before committing.
Why is every property marked as required?
A single sample cannot reveal which fields are optional — absence in one example proves nothing about the contract. The generator marks everything required by default; untick that option or hand-edit the required array down to the keys your API truly always returns.
How does the generator infer types and formats?
It walks the parsed document, mapping each value to its schema equivalent: strings become type: string with format hints (email, uuid, date-time, uri, ipv4) detected from their shape, arrays carry an items subschema built from their elements, and nested objects recurse into properties.
Is the sample payload uploaded anywhere?
No. Inference runs entirely in your browser tab with native JSON.parse, and Toolk’s page analytics do not receive your payload. That matters because real samples often embed customer PII — nothing leaves the device, and generation keeps working offline once loaded.
How do I validate real traffic against the generated schema?
Export the schema, wire it into a validator such as Ajv in your test suite, then replay captured responses against it. To tighten the loop further, generate matching TypeScript interfaces from the same sample with Toolk’s JSON to TypeScript converter (/tools/json-to-typescript).