JSON Schema Generator

Sample JSON:

Use a representative object, array, primitive, or list of similar objects; do not paste secrets or customer data.

Schema title:

From 1 to 80 characters; invalid filename characters are normalized only in downloads.

Schema draft:

Draft 2020-12 uses prefixItems for tuples; older choices use array-form items.

Required properties:

The common-key policy is safer when arrays contain several representative records.

Unknown object keys:

Omitting the keyword leaves the validator default open; closing objects can break forward-compatible producers.

Array inference:

Use tuples only for fixed-position arrays such as coordinate or protocol records.

Null handling:

Null and missing keys are distinct contract decisions.

Enum inference:

The generator caps enum candidates at six distinct values and flags every inferred enum for review.

Enum value limit:

Use 2 to 12; enum candidates still require repeated observations.

values

Schema $id:

The neutral default is blank.

Detect string formats:

The neutral default is off; format remains an annotation unless the downstream validator asserts it.

Include sample examples:

The neutral default is off because annotations may copy sensitive values.

Include observed bounds:

The neutral default is off because observed extrema are not automatically production limits.

Add description stubs:

The neutral default is off; enabled stubs are review scaffolding, not final documentation.

Sort object properties:

The neutral default preserves source order; sorting changes presentation only.

{{ values.schema_text }}

The chart renderer is unavailable. Type counts remain available in the property ledger.

Path	Type	Required	Constraints	Evidence	Copy
{{ row.path }}	{{ row.type }}	{{ row.required }}	{{ row.constraints }}	{{ row.evidence }}

Review before enforcement

Level	Area	Evidence	Review action	Copy
{{ row.level }}	{{ row.area }}	{{ row.evidence }}	{{ row.action }}

A JSON payload is evidence of one event, response, or configuration. A JSON Schema is a claim about every value that should be accepted. Turning the first into the second can save time, but the gap between an example and a dependable contract still needs human decisions.

Type clues are usually the easy part. A whole number suggests integer, an object exposes named properties, and an array supplies item examples. The harder questions concern absence and change. A key seen in every sampled object may still be optional in partial updates, while a value that repeats twice may not define the full set of valid states.

Sample evidence and the JSON Schema decisions it cannot settle alone
Observed evidence	Reasonable draft	Decision still required
A key appears in every record	Add it to `required`	Can older, partial, or future records omit it?
Several values share one type	Use that type for the property	Are other types valid in production?
A few strings repeat	Propose an `enum`	Is the business domain truly closed?
The sample has minimum and maximum values	Propose bounds	Are those real limits or only observed extremes?

Draft choice also changes the vocabulary. Draft 2020-12 represents position-specific tuple entries with prefixItems, while the older supported drafts use an array form of items. A validator must understand the same draft declared by the schema.

A useful inferred schema is therefore a reviewable starting contract. Test it against several valid records, deliberately invalid records, and examples of likely future change. That process reveals where the draft is too strict, too open, or based on evidence that was never representative.

Sample data can contain customer details, tokens, internal identifiers, or other sensitive values. Remove them before sharing a generated schema, especially when sample examples are included as annotations.

How to Use This Tool:

Start with representative JSON, then choose how much of the observed shape should become an enforceable rule.

Paste or load a valid JSON object, array, primitive, or collection of similar records in Sample JSON. Fix the reported line and column if parsing fails.
Enter a Schema title and select the Schema draft used by the downstream validator.
Choose the required-property, unknown-key, array, null, and enum policies. Use fixed tuples only for arrays whose positions have distinct meanings.
Enable format detection, examples, observed bounds, description stubs, or property sorting only when those additions support a specific review need.
Read the Review findings before copying the schema. Repeated enums, mixed types, ignored nulls, empty structures, and sample-derived limits all need deliberate confirmation.

Interpreting Results:

The generated schema describes the selected inference policy, not the full business domain. A low review count means the sample passed the chosen local rules; it does not prove that the schema accepts every legitimate payload or rejects every bad one.

Check the root type and property paths against the data shape you intended to model.
Treat every inferred enum and observed bound as a proposal until broader examples support it.
Verify that nullable values and missing keys remain distinct wherever the application treats them differently.
Test closed objects with a plausible future field before setting additionalProperties to false.

Technical Details:

Schema inference walks the parsed JSON tree and groups values observed at the same path. Each group is classified as object, array, string, integer, number, boolean, or null. Mixed groups become anyOf branches, while uniform groups receive the keywords that apply to that type.

Rule Core:

The following rules are applied in order. They are deterministic for the same sample and settings.

JSON Schema inference rules
Area	Inference rule	Important boundary
Required keys	Use keys found in every sampled object, every observed key, or no `required` array.	A single object makes every observed key common.
Unknown keys	Omit `additionalProperties`, emit `false`, or emit `true`.	Omission leaves the normal open-object behavior in place.
Arrays	Merge all item samples into one item schema or infer a schema for each tuple position.	Draft 2020-12 uses `prefixItems`; Draft 2019-09 and Draft 7 use array-form `items`.
Nulls	Keep null beside non-null types, treat it as observed strict evidence, or ignore it when non-null evidence exists.	A missing property is never treated as a null value.
Enums	Infer repeated primitive values only when at least two distinct values occur and at least one observation repeats.	The distinct-value limit is adjustable from 2 to 12 and defaults to 6.
Annotations	Optionally detect common string formats, copy up to three examples, add observed extrema, or add description stubs.	Formats are annotations unless the chosen validator asserts them.

Observed bounds map to minLength and maxLength for strings, minimum and maximum for numbers, and minItems and maxItems for arrays. No extrapolation is made beyond the sample.

Inference accepts up to 200,000 source characters, stops a branch after 40 nested levels, and caps the property ledger at 5,000 rows. An empty array receives an open item schema because it supplies no item type evidence.

Property sorting changes presentation only. The schema title is required, $id is optional, and the selected draft URI is always written to $schema.

Privacy Notes:

Inference runs in the browser and does not require a server request. Values copied into examples remain visible in the schema, so remove secrets, personal data, and internal identifiers before saving or sharing it.

Worked Examples:

Two records with one optional key

For [{"id":1,"state":"queued"},{"id":2,"state":"sent","note":null}], merged array inference finds object items. With the common-key policy, id and state are required while note remains optional. The result still needs examples without state and with non-null notes before those rules can be treated as complete.

References:

JSON Schema Draft 2020-12, JSON Schema, 16 June 2022.
JSON Schema 2020-12 Release Notes, JSON Schema.
JSON Schema Object Reference, JSON Schema.