JSON Schema Generator

Generate a draft 2020-12 schema from JSON examples and check their observed types locally.

Interpret input as

JSON examples

Infer structure, not business rules. Required properties are those present in every observed object at that location. Numbers that lose intended decimal digits or exceed safe integer precision are rejected. Up to 512 KiB of UTF-8 input.

Local file and schema options

Open a local UTF-8 file

Disallow unobserved object properties (additionalProperties: false). Leave off for a more permissive starting schema.

Draft 2020-12. No format, enum, bounds, patterns or date inference. Every supplied example is checked locally against the generated schema with Ajv before a result is retained. Empty arrays cannot reveal an item type.

Input stays in tab memory, with no upload, URL input or persistent history. Optional analytics receives fixed action labels, never source text, variable names, keys, values or filenames.

This tool processes its input contents in your browser instead of sending them to a processing service. Page, asset and fixed usage-measurement requests are described on the Privacy page.

Infer a reviewable draft 2020-12 JSON Schema from one document or multiple explicit examples, then locally check that every sample fits.

How to use it

1Paste JSON and choose one-document or array-of-examples mode.
2Optionally close inferred objects to unobserved properties.
3Generate and review required intersections, observed type unions and empty-array uncertainty.
4Copy or download the schema and add business constraints deliberately.

Example

Input: [{"id":1,"label":null},{"id":2,"label":"new"}] as examples
Output: Required id and label; label accepts null or string.

Examples do not establish complete future validation rules.

What happens to your data

Examples stay in tab memory. No upload, URL input or persistent history. The output contains inferred keys and types; fixed optional analytics omits keys, values and filenames.

Last updated November 2026

Turn representative JSON into a reviewable starting schema rather than writing every property by hand. Generate a JSON Schema draft 2020-12 document from one payload or an explicitly selected array of examples. Observed types are combined conservatively, and each supplied example is checked locally against the result before it is shown.

This is structural inference, not a complete API contract. Examples cannot tell you every valid future value, business constraint or security rule. The output deliberately avoids guessing date formats, enums, length limits, numeric ranges or regular expressions from a few samples.

How it works

Choose one-document mode to preserve an input array as an array. Choose array-of-examples mode to treat each outer element as a separate document; a nested array stays part of its example. At each location, observed values are grouped by JSON type. Integers and non-integer numbers combine to number when both occur. Different types use anyOf, so null remains an explicit allowed type when observed. This does not reinterpret a string such as "123" as a number.

For observed objects, each property is inferred from its observed values, and only properties present in every object at that location are marked required. Missing and null are different: a property can be required and accept null. Unobserved object properties are allowed by default. The optional closed-object setting adds additionalProperties: false at each inferred object; review it before enforcing the schema against future data. Arrays combine the observed item structures without inferring positional tuples. If only empty arrays were observed, items is {}, allowing any item type; the result highlights that uncertainty.

The existing lossless JSON lexer reads number spellings and duplicate keys before values are converted. Duplicate object keys are rejected instead of silently discarding earlier values. Nonfinite numbers, unsafe integers and decimals that cannot round-trip through browser-number decimal text are rejected; use strings for identifiers that exceed safe numeric precision. This guard prevents silent digit collapse but does not provide exact-decimal arithmetic. Keys such as __proto__, constructor and prototype are retained as own data properties in null-prototype maps, never merged into a JavaScript prototype. The exact __proto__ key uses the fixed anchored patternProperties entry ^__proto__$ so the validator enforces its type even in closed objects; this is literal-key handling, not a guessed data pattern.

The inferred keyword subset is compiled locally with the existing Ajv 2020-12 validator, using own-property checks. Every supplied example must pass before an output is retained. No user-supplied schema, remote reference, custom keyword, format assertion or validation URL is executed or fetched. Passing examples proves only that those supplied examples fit the generated rules.

Limits are 512 KiB of valid UTF-8 input, 32 nesting levels, 20,000 lexer tokens, 10,000 JSON value nodes and 1–100 examples. The generated result is limited to 2,000 schema nodes, 1,000 property locations and 512 KiB. A single empty array is valid in one-document mode; an empty outer array supplies no examples and is rejected in examples mode. Malformed JSON, duplicate keys and out-of-range values leave no stale downloadable result.

Input and local files stay in tab memory, without a dataset upload, persistent history or values in the URL. Editing data or settings clears old results. The schema download contains inferred names and structure, not sample values; property names can still reveal confidential system details. Optional analytics uses fixed action labels and input mode, never source text, keys, values or filenames.

Worked example: Missing and nullable fields remain different

Input: [{"id":1,"label":null},{"id":2,"label":"new","note":"optional"}] in array-of-examples mode
Result: An object schema requires id and label. id is integer; label allows null or string; note is an optional string.

Additional properties remain allowed unless you explicitly close inferred objects. No enum or format is guessed.

Common use cases

Create a starting schema for an API payload from representative success and edge-case examples.
Compare optional fields across sample records without treating missing and null as identical.
Document heterogeneous array items while retaining explicit observed type unions.
Generate a local schema and then review the actual business rules in your codebase.

Frequently asked questions

Does an input array mean multiple examples automatically?＋

No. One-document mode treats it as an array document. Array-of-examples mode explicitly treats each outer element as one sample. This prevents silently changing the intended schema root.

How are required properties inferred?＋

At each object location, a property is required only when it appears in every observed object there. A required property may still accept null when null was observed. Samples cannot prove that the field is always required by the real application.

Why are enums or date formats not generated?＋

A few examples do not establish an exhaustive enum or a promised string format. The tool avoids imposing those unsupported constraints. Add them deliberately after reviewing your application requirements.

Why is a large numeric identifier rejected?＋

Browser numbers cannot retain every large integer or long decimal. The generator rejects unsafe or digit-losing input rather than infer from a rounded value. Quote identifiers as strings if that matches the real data contract.

Do all examples passing mean the schema is production-ready?＋

No. It confirms only that the supplied examples match the generated structural rules. Review missing cases, additional-property policy and domain constraints before enforcing it.