JSON Schema Generator

Schema title:

Name the object, API payload, event, or configuration file this sample represents.

Schema draft:

Use Draft 2020-12 for new schemas unless your validator requires an older draft.

Sample JSON:

Paste an object, array, or representative API payload; arrays are treated as sample collections by default.

Required properties:

Common-in-samples is safest for arrays of objects; every observed key is stricter.

Unknown object keys:

Omit leaves validator defaults unchanged; false creates a closed object contract.

{{ item }}

Schema $id:

Leave blank unless this schema will be referenced by validators or other schemas.

Array inference:

Merge is best for API lists; tuple is useful for fixed-position arrays.

Null handling:

Nullable unions preserve fields that sometimes appear as null.

Enum detection:

Use off for open text fields; primitive mode can capture small status/code domains.

Enum value limit:

Use 2 to 12 values; larger sets are usually not real enums.

values

Detect string formats

Adds common format annotations such as email, uri, date-time, date, time, uuid, ipv4, and ipv6.

Include sample examples

Adds examples annotations from the input sample. Review before sharing schemas with external parties.

Include observed bounds

Adds min/max string length, numeric minimum/maximum, and array item counts from observed samples.

Add description stubs

Adds short placeholder descriptions that make review handoffs easier without changing validation.

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

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

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

JSON Schema describes the expected shape of JSON data. It gives teams a shared contract for objects, arrays, strings, numbers, booleans, nulls, required fields, and allowed values before the data reaches an API consumer, configuration loader, event processor, or validation library.

Sample-derived schema generation is useful when a payload already exists but the contract has not been written yet. A representative order event, webhook body, settings file, or log record can reveal field names, nested object paths, array item shapes, and obvious value types faster than writing the first draft by hand.

Sample JSON flowing through inference rules into a generated JSON Schema and review notes

A generated schema is still a draft. One sample can show that customer.email looked like a string and that items looked like an array, but it cannot prove every optional field, future enum value, numeric range, or validator setting. Treat the first result as a structured starting point, then test it against more examples and the validator used by the system that will consume it.

The most important review question is whether the sample is broad enough. A schema generated from only a success response may reject error responses, webhook retries, partial updates, nullable fields, or new status values that are valid in production data.

Technical Details:

JSON Schema separates assertion keywords from annotation keywords. Assertions such as type, required, minimum, maxLength, and additionalProperties affect whether an instance validates. Annotations such as title, description, examples, and many uses of format carry documentation or semantic hints that validators may not enforce by default.

Sample inference starts by parsing one JSON value and walking its object keys, array items, and primitive values. Strings become string, integers become integer, decimals become number, booleans become boolean, arrays become array, objects become object, and nulls require an explicit policy choice when they appear alongside another type.

Inference Core:

JSON Schema inference rules used by the generator
Area	Generated Keyword Pattern	Review Meaning
Root dialect	`$schema` is set from the selected draft, and an optional `$id` is added only when supplied.	Use the same draft in the downstream validator because tuple arrays and format behavior can differ across drafts.
Objects	Observed keys become `properties`; `required` depends on the selected required-property policy.	Common-in-samples is safer for arrays of objects because it does not require a key seen in only one sampled item.
Unknown keys	`additionalProperties` can be omitted, set to `false`, or set to `true`.	Omitting the keyword leaves validator defaults unchanged, while `false` closes the object to unlisted keys.
Arrays	Merge mode produces one `items` schema from all item samples; tuple mode creates position-specific item schemas.	Merge mode fits lists of similar records. Tuple mode fits fixed-position arrays such as coordinates or compact protocol records.
Mixed values	Different non-null types at one path become `anyOf`; nullable mode adds `null` to the inferred type.	Mixed-type output needs manual review because a sample can hide the real discriminator or business rule.
Observed constraints	Optional bounds add `minLength`, `maxLength`, `minimum`, `maximum`, `minItems`, and `maxItems`.	These limits come directly from the sample and may be too narrow for real data.
Small value sets	Enum detection adds `enum` only for repeated primitive values that stay under the selected value limit.	Repeated sample statuses can be useful, but open text fields should not be locked to accidental examples.

Draft selection matters most for tuples. In Draft 2020-12 and Draft 2019-09, position-specific tuple output uses prefixItems with items: false to reject extra positions. In Draft 7, the same intent uses an array form of items with additionalItems: false.

String format detection is a hint, not a proof of reachability or ownership. A value that matches the shape of an email address, URI, date-time, UUID, IPv4 address, or IPv6 address can receive a format annotation, but the JSON Schema specification treats format assertion support as implementation-dependent unless a validator explicitly enables it.

Review Boundaries:

Boundaries for interpreting generated JSON Schema output
Generated Signal	What It Can Tell You	What Still Needs Checking
`required` count	How many keys the selected policy marked as mandatory at observed object paths.	Whether omitted keys in other valid examples should remain optional.
`enum`	A small repeated set appeared in the sample values.	Whether future status codes, regions, methods, or labels are valid but absent from the sample.
`format`	All non-empty strings at that path matched a supported pattern.	Whether the validator treats that format as an assertion and whether the value is meaningful to the application.
Observed bounds	The sample showed current minimum and maximum lengths, numbers, or item counts.	Whether production payloads can be longer, smaller, larger, or contain more array items.
Description stubs and examples	Annotations can make handoff review easier and show sample values at a path.	Whether any copied examples reveal sensitive, internal, or temporary data.

A compact mechanism path looks like this: an array of two order items is parsed, both item objects are merged, shared keys such as sku and quantity become item properties, repeated string values may form an enum only when the enum setting allows it, and review notes flag choices that should be tightened or relaxed before release.

Everyday Use & Decision Guide:

Start with Draft 2020-12, Require keys present in every sampled object, Omit additionalProperties, and Merge array item samples. That first pass is a good fit for API lists, webhook events, and configuration files where arrays usually contain many records with the same shape.

Use a clear Schema title such as OrderEvent, UserProfile, or BillingConfig. Add Schema $id only when the schema will be referenced by other schemas or managed as a stable contract. A casual draft does not need an identifier.

Switch Required properties to Do not emit required arrays when the sample is incomplete or comes from a partial update.
Choose Set additionalProperties false only when extra object keys should fail validation.
Use tuple arrays for fixed-position data; keep merged arrays for lists of similar objects.
Turn on observed bounds only when the sample is known to contain real business limits rather than accidental current values.
Leave enum detection off for names, comments, identifiers, and other values that can grow without a release.
Review examples before sharing output when sample values include customer, host, token, or internal environment details.

The practical stop sign is Inference Notes. Mixed types, ignored nulls, empty arrays, empty objects, observed bounds, and copied examples all deserve a second look before the schema is used as a validation contract.

Use Property Ledger to review paths, required status, constraints, and evidence before copying the generated schema. The ledger is often faster to audit than the full JSON when the sample has several nested objects.

Step-by-Step Guide:

Use one broad sample first, then tighten the generated contract after the review tables make sense.

Enter Schema title and choose Schema draft. The summary should update to the title and selected draft.
Paste JSON into Sample JSON, use Browse JSON, drop a JSON or text file, or load the built-in order event sample.
Use Format if the source is hard to scan. If parsing fails, the input alert reports the JSON error and may include the line and column.
Set Required properties and Unknown object keys before reading the schema, because those choices can change validation strictness for many object paths.
Open Advanced for Schema $id, Array inference, Null handling, enum detection, format detection, examples, observed bounds, and description stubs.
Check the summary count, then read Generated Schema and Property Ledger together. The schema shows the contract; the ledger shows why each path was inferred.
Open Inference Notes and resolve review or warning rows, especially mixed types, empty arrays, observed bounds, and examples copied from the sample.
Validate several real payloads with the chosen JSON Schema validator before treating the output as release-ready.

Interpreting Results:

The summary count tells you how much structure was inferred, not how complete the schema is. A payload with 24 inferred properties can still miss optional fields, alternate response shapes, or rare enum values.

How to interpret JSON Schema Generator results
Result Cue	Meaning	Next Check
`Fix sample JSON`	The source did not parse, so the schema output is an error object.	Repair the JSON syntax before reviewing any inferred paths.
`Property Ledger` required badge	The selected required policy marked that path as required, optional, root, or item evidence.	Compare the row against valid examples where that key may be absent.
`mixed` constraint	Different JSON types appeared at the same path and were represented with `anyOf`.	Decide whether the field really accepts multiple types or whether the sample needs cleanup.
`Observed bounds` warning	Length, numeric, or array count limits came from the sample's current extremes.	Relax those keywords unless the sample covers the real allowed minimum and maximum.
`Examples included`	Sample values were copied into schema annotations.	Remove sensitive examples before sharing the schema outside the team that owns the data.

A clean notes table does not prove the schema is final. It means the current sample and settings did not trigger the generator's review warnings. Confidence comes from validating more examples, checking optional fields, and confirming the exact draft with the validator that will enforce the contract.

Worked Examples:

Order event starter schema:

An order event with id, type, created_at, customer.email, and two items entries should infer an object root with nested properties. With format detection on, timestamp and email-shaped strings can receive date-time and email format annotations. Property Ledger should show paths such as $.customer.email and $.items[].quantity, with evidence counts tied to the sample.

Fixed-position array:

A coordinate sample such as [101.6869, 3.139] should use tuple array inference when the first position always means longitude and the second always means latitude. Under Draft 2020-12, the generated schema uses position-specific entries through prefixItems. Under Draft 7, the same kind of tuple uses an array form of items plus additionalItems: false.

Null value review:

If metadata is null in one sample but an object in another, nullable handling should include both the object shape and null. If null handling is set to ignore, Inference Notes reports that null samples were ignored when another type was present. That row should be resolved before the schema is used for payloads where null is valid.

Parse failure:

A missing comma after "id": "evt_123" stops inference. The summary changes to Fix sample JSON, the input alert reports the parse problem, and the result JSON contains the error instead of a usable schema. After the comma is fixed, the summary returns to a property count and the generated schema can be reviewed normally.

FAQ:

Can I use the generated schema as-is?

Use it as a first draft. Review Property Ledger and Inference Notes, then validate several real payloads before the schema becomes a release contract.

Why did a field become required?

The selected required-property policy controls that result. Require keys present in every sampled object marks a key required only when it appeared in every object sample at that path.

Why did the output use anyOf?

anyOf appears when sample values at one path have different JSON types. Check whether that mixed type is expected or whether the sample contains inconsistent data.

Do format hints guarantee valid emails or URLs?

No. The generator recognizes common string patterns and adds format annotations, but validators differ in whether they enforce those annotations as validation failures.

What should I do with an empty array warning?

Add at least one representative item before trusting the array schema. Without item samples, the generated items shape cannot describe the records that should appear there.

Does pasted JSON leave the browser for inference?

The schema inference runs in the browser, and loaded files are read into the page for local parsing. Review generated examples before sharing output because examples can copy sample values into the schema.

Glossary:

JSON Schema: A JSON-based vocabulary for describing and validating the shape and rules of JSON data.
Instance: The JSON value being checked against a schema, such as an API response or configuration object.
Assertion keyword: A keyword that can affect validation, such as type, required, or minimum.
Annotation keyword: A keyword that adds information for documentation or consumers, such as title, description, or examples.
additionalProperties: An object rule that controls keys not listed under properties.
prefixItems: A Draft 2020-12 array keyword for validating tuple positions with separate schemas.
anyOf: A composition keyword used here when sample values at one path have multiple possible JSON types.
Format annotation: A string hint such as email, date-time, or uuid that validators may treat differently.

References:

JSON Schema Specification, JSON Schema.
JSON Schema Draft 2020-12, JSON Schema, 16 June 2022.
JSON Schema Core, JSON Schema, 16 June 2022.
JSON Schema Validation, JSON Schema, 16 June 2022.