JSON Schema Generator

What this tool does

This tool reads a sample JSON document and infers a JSON Schema that describes its shape. It walks the value recursively: objects become a properties map with a required list, arrays get an items schema, and scalars are classified as string, number, integer, boolean or null. The result is a draft-07 schema, declared with the standard $schema keyword, that you can drop straight into a validator. The inference runs entirely in your browser — your sample is never uploaded.

Why you might need it

Writing a JSON Schema by hand is tedious, especially for a large or deeply nested payload. If you already have a representative example — an API response, a config file, a fixture — it is much faster to generate a schema from it and then refine. A schema is useful for validating incoming data before you trust it, documenting the contract of an API, generating typed code in languages that support it, and catching regressions when a payload silently changes shape. Even as a one-off, generating a schema is a quick way to get a precise, machine-readable description of what a JSON document actually contains.

How to use it

1. Paste a representative JSON document into the input box, or drop a .json file.
2. Click Generate schema, or press Ctrl/Cmd + Enter.
3. The inferred draft-07 schema appears below as pretty-printed JSON.
4. Copy it with the copy button and paste it into your validator or repo.
5. Refine the result — add formats, ranges, patterns and descriptions by hand.

The Load sample button provides a JSON document with nested objects and arrays so you can see how the inference handles each structure.

How inference works

For an object, every key becomes an entry in properties, and every key present in the sample is added to required — because the tool only sees one example, it assumes everything it saw is mandatory. For an array, the tool infers a schema for each element and merges them into a single items schema; when elements disagree, the type becomes a list of all observed types and object properties are combined. An empty array produces { "type": "array" } with no items, since there is nothing to infer from. Numbers split into integer (no fractional part) and number, and null is reported as the null type.

Common pitfalls

The biggest limitation is that a schema can only describe what the sample showed. If a field is optional in real life but present in your example, it will be marked required. If a field is sometimes a string and sometimes null, but your sample only had the string, the schema will not allow null. Give the richest, most representative example you can — ideally an array containing several varied objects — so the merge logic sees the real range of values. Also remember the tool cannot infer semantic rules: a date string is just a string, an email is just a string, and a value capped at 100 has no maximum. Add those constraints yourself.

Tips and advanced use

To get a schema that tolerates real-world variation, feed the tool an array of several example objects rather than a single one — the per-element merge will widen type lists and relax the required set automatically. Once you have the draft, layer on format (for dates, emails, URIs), enum for fixed value sets, and minimum/maximum or pattern where they apply. Because the whole process is client-side, you can safely generate a schema from production data; none of it leaves your browser.