🧬 JSON Schema Generator
Paste a JSON example and get a draft-07 JSON Schema describing it, types, nested objects, arrays and required fields inferred for you.
JSON Schema draft-07
How the json schema generator works
The generator parses your JSON sample and walks it to infer a JSON Schema (draft-07). Whole numbers become "integer" and other numbers "number"; strings, booleans, arrays and nested objects are each described in place. For an array of objects it merges the elements into one item schema, marking a property as required only when it appears in every element. Every object lists its always-present keys under "required". The result is valid draft-07 you can drop into validation, an OpenAPI spec, or a form generator.
A JSON Schema inferred from one example is a strong starting point, not a finished contract. You will usually tighten it by hand: adding formats (date-time, email), min/max constraints, enums, and descriptions, and relaxing "required" where a field is genuinely optional. Because inference sees only the sample you give it, a richer example (covering optional fields and edge cases) produces a better schema. Everything runs locally, so proprietary payloads never leave your browser.
Frequently asked questions
How do I generate a JSON Schema from JSON?
Paste a representative JSON example and the tool infers a draft-07 schema, object properties, array item types, and which fields are required. Copy the result and refine it as needed.
Which JSON Schema version does it produce?
Draft-07, the most widely supported version across validators, OpenAPI tooling and form libraries. The output includes the $schema declaration so validators recognise it.
How does it decide what is "required"?
For a single object, every key present is marked required. For an array of objects, a property is required only if it appears in all of them, so optional fields (missing from some elements) are left out of "required".
Why should I refine the generated schema?
Inference only knows the sample you gave it. It can’t guess string formats (email, date-time), numeric ranges, enums, or which fields are truly optional. Treat the output as a scaffold and add those constraints yourself.
What is the difference between "integer" and "number" in the schema?
JSON Schema types a whole-number sample (like 42) as "integer" and a value with a fractional part (like 3.14) as "number". If a field is conceptually a float that just happens to be whole in your sample, say a price of 10, widen it to "number" by hand so 10.5 also validates.
How are arrays described?
An array becomes {"type":"array","items":…}, where items is the schema of the elements. For an array of objects, the tool merges the objects into one item schema and marks a property required only if every element has it, so mixed or optional fields are handled sensibly rather than assumed mandatory.
Does it detect string formats like email or date-time?
No, from a sample it can only see that a value is a string, not what kind of string it is. JSON Schema's "format" keyword (email, date-time, uri, uuid) has to be added by hand afterwards, because two strings like "2026-01-01" and "hello" are indistinguishable to type inference.
How is a null value in the sample typed?
A field whose sample value is null is typed "null", which only ever validates null. If the field can also carry a real value, widen it by hand, for example {"type":["string","null"]}, since a single null sample can't reveal the underlying type.
Is my JSON uploaded?
No, parsing and schema generation run entirely in your browser and work offline, so sensitive payloads stay on your device.