JSON Schema Generator
Generate a JSON Schema from sample JSON, with nested object, array, and required field detection.
What is a JSON Schema Generator?
A JSON Schema generator infers a JSON Schema— a formal description of a document's structure, types, and required fields — directly from a real sample of JSON, such as an API response or a config file. Instead of hand-writing every type, properties, and required entry, you paste an example and get a draft schema back instantly.
This tool walks your sample recursively: every key gets a type (string, number, integer, boolean, object, array, or null), nested objects become nested properties, and arrays are inferred from the union of shapes across every item they contain — so an array of objects with slightly different fields still produces one accurate items schema.
The generated schema is a starting point, not a final contract. Keys observed in your sample are marked required by default (turn this off with the Require observed keystoggle if your sample doesn't cover every optional field), and you should review types like numeric strings or date formats that JSON Schema alone can't distinguish from plain text.
Choose between Draft-07 and 2020-12 for the $schemadeclaration depending on which validator or tool you're targeting. Everything runs locally in your browser — your JSON is never uploaded to a server.
Why Generate a JSON Schema?
API Contracts
Turn a real API response into a schema you can attach to documentation or an OpenAPI spec, without writing it by hand.
Request Validation
Use the schema with a validator library (like Ajv) to reject malformed payloads before they reach your application logic.
Documentation
A schema is a precise, language-agnostic reference for what a payload looks like — far less ambiguous than a prose description.
Config Validation
Generate a schema from a working config file, then use it to catch typos and missing fields in future edits.
Draft-07 vs. 2020-12: Which Should You Pick?
Both are versions of the JSON Schema specification, identified by the $schema URI at the top of the document. For the kind of schema this tool generates — type, properties, required, and a single-shape items — the two drafts behave identically, so switching the Draft selector only changes that one line. The differences that do exist between them show up in more advanced schemas than a generated draft typically needs:
- Tuple arrays. Draft-07 validates a fixed-position array (e.g.
[string, number]) with an array of schemas initems. 2020-12 moved that to a dedicatedprefixItemskeyword and reservesitemsfor constraining any remaining elements — irrelevant here since this tool only ever produces a singleitemsschema shared by every element. - Recursive references. Draft-07 uses
$recursiveRef/$recursiveAnchorfor self-referencing schemas; 2020-12 replaced them with the more flexible$dynamicRef/$dynamicAnchor. - Vocabularies.2020-12 splits the specification into separate vocabularies (core, validation, applicator, and so on) that a schema can declare support for, instead of Draft-07's single monolithic meta-schema.
unevaluatedProperties/unevaluatedItems. Introduced after Draft-07 (in draft 2019-09) and refined in 2020-12, these keywords constrain properties or items left unmatched byallOf/if-then-elsecomposition — a feature this tool's output doesn't use.
In practice: pick Draft-07if you're targeting an older validator, tool, or ecosystem (it's still the most widely supported draft across languages). Pick 2020-12 — the current version of the specification — for new projects, especially if you expect the schema to grow into tuple validation or recursive structures later.
Example
A sample payload with a nested object and an array of objects with an optional field — notice that note is left out of requiredsince it isn't present on every order.
{
"id": 1,
"name": "Ada Lovelace",
"email": "ada@example.com",
"active": true,
"score": 98.5,
"address": {
"city": "London",
"zip": "SW1A 1AA"
},
"tags": ["mathematician", "writer"],
"orders": [
{ "id": "ord_1", "total": 42.5, "note": "Gift wrap" },
{ "id": "ord_2", "total": 15 }
]
}{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"id": { "type": "integer" },
"name": { "type": "string" },
"address": {
"type": "object",
"properties": {
"city": { "type": "string" },
"zip": { "type": "string" }
},
"required": ["city", "zip"]
},
"tags": {
"type": "array",
"items": { "type": "string" }
},
"orders": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"total": { "type": "number" },
"note": { "type": "string" }
},
"required": ["id", "total"]
}
}
},
"required": ["id", "name", "email", "active", "score", "address", "tags", "orders"]
}Features
Type Inference
Detects string, number, integer, boolean, object, array, and null for every key in your sample.
Nested Objects
Recurses into nested objects at any depth, generating a full properties tree.
Array Support
Infers an items schema from the union of shapes across every array element.
Required Field Detection
Marks keys present on every observed instance as required, with an editable toggle.
Download Schema
Save the generated schema as a standalone .json file for your project or docs.
A Note on the "Required" Assumption
Since a single sample can't tell this tool which fields are truly optional, it assumes every key it observes is required — for objects that appear once, that means all of their own keys; for objects merged from multiple array items, only the keys common to every item are kept. This is a reasonable default for a first draft, but it is an assumption, not a fact about your data. Toggle Require observed keys off to generate a schema with types only and no required arrays, then add back the fields you know are mandatory.