JSON Schema Generator
Generate a JSON Schema structure from sample JSON data.
JSON Schema Generator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The JSON Schema Generator infers a JSON Schema document from a real sample JSON payload — analyzing the structure, types, and shape of your example data and producing a schema that describes it. Writing a JSON Schema by hand from scratch is tedious and error-prone for anything beyond a trivial payload; starting from a generated draft based on a real example and refining it is almost always faster and more accurate than authoring one from a blank file.
- The generated schema captures what your sample data actually looks like: which properties exist, their types (string, number, boolean, object, array, null), and the nesting structure for objects and arrays. It does not know your intent beyond what's observable in the example — it can't infer that a field you left out of your sample is actually required, or that a number field should be constrained to a specific range, unless your sample or your own edits make that explicit.
- This tool pairs directly with the JSON Schema Validator: generate a starting schema from a representative payload here, then refine it by hand (adding required fields, format constraints, or enum restrictions your sample didn't capture), and use the Validator to confirm future payloads actually conform to the refined schema.
How It Works
- The input JSON payload is parsed and its structure walked recursively.
- For each property, the tool records its JSON type (string, number, boolean, object, array, or null) and, for objects, recurses into their own properties.
- For arrays, the tool inspects the contained items to infer an appropriate items schema — treating the array as containing a consistent type when the sample supports that, or a more general schema when items vary.
- The result is assembled into a valid JSON Schema document (draft 2020-12 by default) describing the shape observed in your sample.
- Because the schema is inferred from one example, it should generally be treated as a starting draft — reviewed and tightened by hand before being relied on as an authoritative contract.
Usage
- Paste a representative sample of your JSON payload — ideally one that includes every field you care about validating, including any optional or nested structures.
- Generate the schema.
- Review the inferred types and structure, and refine by hand: mark genuinely required fields as required, add format or range constraints the sample alone couldn't reveal, and remove or adjust anything the inference got wrong.
- Use the JSON Schema Validator to test the refined schema against additional real payloads, including edge cases your original sample didn't cover.
Examples
- Generating a schema from a sample API user object, then manually marking id and email as required since every real record must include them even though a single sample can't prove that on its own.
- Generating a schema from a nested configuration object and reviewing that array fields were inferred with a sensible items type rather than left overly generic.
- Generating a baseline schema from a real payload and comparing it against an existing hand-written schema to spot a field the hand-written version had missed entirely.
- Generating a schema from a minimal example, then adding an enum constraint by hand to a status field, since the sample alone only showed one of several valid values.
Real-World Use Cases
- Quickly bootstrapping a JSON Schema for an existing API response or configuration format that doesn't yet have one documented.
- Generating a baseline schema to compare against a hand-written specification, to spot fields the specification missed or got wrong relative to real data.
- Creating a starting point for API documentation that includes a formal schema, without authoring the entire structure by hand.
- Producing a first-draft schema for a new internal data format before it's been formally specified, to use immediately in validation while the specification is finalized.
Best Practices
- Use a genuinely representative sample — one with every field populated, including optional and nested ones — rather than a minimal example, since the tool can only describe what it actually sees.
- Always review and tighten a generated schema before treating it as an authoritative contract — mark required fields explicitly, add format/range constraints, and remove overly permissive inferences the sample alone couldn't justify.
- Regenerate or re-check the schema periodically against fresh real payloads as your data format evolves, rather than letting a schema silently drift out of sync with what's actually being sent.
- Pair schema generation with the JSON Schema Validator in your actual workflow — generate once, validate continuously, rather than treating schema generation as a one-time task.
Common Mistakes
- Treating a freshly-generated schema as complete and authoritative without review — it reflects exactly one example, not the full space of valid inputs your application should actually accept.
- Generating from a minimal or incomplete sample and ending up with a schema that's missing fields entirely, rather than using a fully-populated representative example.
- Forgetting that inferred fields are not marked required by default — a generated schema typically needs explicit review to mark which fields genuinely must be present versus which happened to be present in the one sample used.
- Assuming inferred type constraints (like a number's likely range, or a string's likely format) are meaningful — the generator reports what type a value is, not what values are actually valid, which requires your own domain knowledge to specify.
Limitations
- The generated schema reflects only the structure of the sample payload provided — it cannot infer required-vs-optional distinctions, format constraints, or valid value ranges that aren't directly observable from that one example.
- Arrays with genuinely mixed-type or inconsistent-shape items may produce a broader, less precise items schema than a hand-tuned one would.
- This tool generates a schema from an example; for validating payloads against an existing schema, use the JSON Schema Validator instead.
Technical Reference Guide
- JSON Schema is specified by the JSON Schema project's own specification (currently draft 2020-12), maintained independently of the core JSON grammar itself (RFC 8259).
- The core structural keywords a generated schema relies on — type, properties, items, required — are defined in the JSON Schema Core and Validation specifications.
- JSON Schema is not part of the JSON RFC itself; it's a separate, widely-adopted convention for describing JSON document structure, distinct from the data format it describes.
FAQ
Does the generated schema mark fields as required?
Not by default — the tool can only observe that a field was present in your one sample, not that it must always be present. Review the generated schema and mark genuinely required fields by hand.
Can I generate a schema from multiple different examples?
Generate from your most fully-populated, representative example for the best starting point; if your data has meaningfully different shapes in different cases, you may need to merge or manually reconcile schemas generated from each variant.
Why didn't the generator add a format constraint to my email field?
The generator infers JSON types (string, number, and so on) from structure, not semantic meaning — it can't know a string field represents an email address specifically unless you add that constraint yourself after generation.
What JSON Schema draft version does this generate?
Draft 2020-12 by default, the current version of the specification — check compatibility if your validation tooling expects an older draft.
Should I use the generated schema directly in production?
Treat it as a starting draft, not a finished contract — review and tighten it (required fields, format constraints, value ranges) based on your actual requirements before relying on it as an authoritative validation schema.
What should I do after generating a schema?
Refine it by hand for anything the sample alone couldn't capture, then use the JSON Schema Validator to test it against additional real payloads, including deliberately unusual or edge-case ones your original sample didn't cover.
Part of this Developer Hub
This utility is part of our comprehensive JSON Workshop topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the API & Web Engineering Lab workshop for complementary engineering workflows.
View all API & Web Engineering Lab tools