Generate a draft-07 JSON Schema from a sample JSON document, with format detection.
Generated locally — your sample data never leaves your browser.
How do you create a JSON Schema from sample JSON?
Map each value to its type — objects become "object" with a properties map, arrays become "array" with an items schema, whole numbers become "integer" — and wrap it with the draft-07 $schema declaration. A schema inferred from one sample needs review: optional fields and value constraints cannot be inferred.
Understanding your result
The most useful thing you can do is feed it a good sample. A document with every optional field populated produces a far more complete schema than a minimal one, and passing an array of several objects lets the generator merge their shapes — keys present in only some of them are then correctly left out of the required list, which single-sample inference can never work out. After generating, two edits are almost always worth making by hand: relax the required list to only the fields your API genuinely guarantees, and add value constraints such as minimum, maxLength or enum, since no amount of sampling can infer the rules behind the data.
Formula and method
Each value is mapped to its JSON Schema type: objects become type "object" with a properties map, arrays become type "array" with a merged items schema, and whole numbers are typed as integer rather than number. Strings are pattern-matched against known formats.
Assumptions and limitations
A schema inferred from one sample describes that sample, not your whole API. Optional fields absent from the example will be missing entirely, a field that happens to be null is typed as null rather than as the type it usually holds, and no value constraints — minLength, minimum, pattern, enum — can be inferred from a single instance. Treat the output as a strong first draft to review and tighten by hand.
Worked example
A user object with a uuid id, an email, an integer age, a boolean, an ISO timestamp, a string array and a nested address produces a schema describing all eight properties, with uuid, email and date-time formats detected automatically.
How to use this tool
- Paste a representative JSON document — ideally one with every optional field filled in.
- Give the schema a title.
- Choose whether every key should be required and whether extra properties are allowed.
- Copy the schema, then review the required list and add constraints.
Common mistakes to avoid
- Using a minimal sample, so optional fields are missing from the schema.
- Leaving every key required when your API returns some conditionally.
- Accepting a null-typed field that normally holds a string.
- Shipping the generated schema without adding any value constraints.
About the JSON Schema Generator
The JSON Schema Generator infers a draft-07 schema from a sample JSON document. It distinguishes integers from floats, describes nested objects and arrays, merges the shape of array items so mixed arrays are described honestly, and can detect string formats such as email, uuid, date and uri.
Who should use this tool
API developers documenting payloads, teams adding request validation and anyone writing contract tests.
Benefits
- Merges the schemas of array items rather than trusting the first element.
- Marks a key required only when it appears in every sampled object.
- Detects seven common string formats automatically.
- Distinguishes integer from number, which most generators miss.
Practical use cases
- Documenting the shape of an API response.
- Adding request validation to an endpoint.
- Generating a starting schema for OpenAPI documentation.
- Writing a contract test against a third-party payload.
Explore all Developer Tools tools
Frequently asked questions
Which JSON Schema draft is produced?
Draft-07, which is the most widely supported version across validation libraries and tooling.
How are arrays with mixed types handled?
The schemas of all items are merged, so the items definition covers every element rather than describing only the first one.
Why is a field typed as null?
Because it was null in your sample and there is no way to know what type it normally holds. Edit that field by hand, or supply a sample where it is populated.
Should I mark every property as required?
Only those your API always returns. Requiring everything makes validation reject perfectly valid responses that omit an optional field.
What does additionalProperties: false do?
It rejects any property not listed in the schema. That catches typos, but it also breaks validation the moment your API adds a new field, so use it deliberately.