How does it decide which keys are required?

For a single object, every key present is marked required by default, and you can switch that off. For an array of objects the rule is stricter and more useful: required is the intersection of keys present in every element, while properties is the union of all keys seen anywhere. A key that appears in some records but not others is therefore an optional property, which is almost always what you meant.

Which string formats does it detect?

Conservative, high-confidence ones: email, uri, uuid, date, date-time, ipv4 and ipv6. Detection is deliberately cautious. A string that merely could be a date is left as a plain string rather than constraining your schema to a format your real data may violate. Over-tight inferred schemas are worse than loose ones because they fail on valid records later.

What happens with mixed-type arrays?

The item schemas are unified into a single type union: an array holding a number, a string and a boolean produces items with "type": ["integer", "string", "boolean"], which is compact and valid in both drafts. For an array of objects with differing keys, required becomes the intersection of keys present in every element while properties is the union of every key seen, so a key that appears in only some records is correctly optional. Empty arrays produce an unconstrained items schema, because a sample of zero elements tells you nothing about what belongs in them.

How are null values handled?

A key whose only observed value is null is typed as null. A key seen as both null and something else becomes a union of the two types, which is the correct reading of nullable data. This matters because the naive alternative (treating null as "no information" and dropping it) produces a schema that rejects the very document it was generated from.

Which draft should I use?

Draft 2020-12 is current and the right default for new work. Draft-07 is offered because a great deal of tooling (older validators, some code generators and several API frameworks) has not moved on. For the schemas this tool emits the two outputs are identical apart from the $schema URI they declare, so switching is safe and you can pick whichever your validator expects.

Is my JSON uploaded anywhere?

No. Inference runs entirely in your browser, which is the point: the sample document you want a schema for is usually a real API response or a production record, and those routinely contain customer data. There is no request to inspect because there is no server to send it to.

How do I generate a JSON Schema from an array of objects?

Paste the whole array as one JSON value. For [{"id":1,"name":"A"},{"id":2}], the item schema includes id and name but requires only id: it appears in every record. Properties are the union of observed keys, and required is their intersection. An empty array has no observed item constraints. Include representative records, not only the easiest example.

What do format and enum detection add?

Format detection adds a recognized string format only when every observed string at that location matches it. Enum inference uses small repeated string sets; a few examples can over-constrain future values, so switch it off when the sample does not represent every allowed value. The adjacent validator treats format as annotation and does not assert it.

Can I validate the generated schema against my sample?

Copy a Draft 2020-12 result into [JSON Schema Validator](/json-schema-validator) and paste the sample as the instance. Review that validator’s unchecked-keyword notices. It supports a bounded set of 2020-12 constraints; a Draft-07 output needs a validator that supports that dialect. Passing the sample still does not prove that the inferred schema describes all future records.

Can it generate JSON data from a schema, classes, forms or documentation?

This page performs sample-to-schema inference only. It does not reverse a schema into example or test data, generate forms, diagrams, database schemas, documentation, Avro or protobuf contracts. For Dart classes or TypeScript types from supported JSON or JSON Schema, use [JSON to Dart and TypeScript](/json-to-code). That generator does not turn every schema constraint into a type assertion.

Is JSON Schema the same as JSON-LD, schema.org or OpenAPI?

No. JSON Schema describes constraints on JSON values. [Schema Markup Generator](/schema-markup-generator) builds JSON-LD for its four supported schema.org types. An API response sample does not contain the paths, operations and parameters needed to construct an OpenAPI contract. This page also does not translate XSD, Zod, YAML schemas or language classes into JSON Schema. To reserialize an existing JSON Schema document as YAML values, use [JSON to YAML](/yaml-to-json/json-to-yaml); its keywords remain values rather than being translated into another schema language.

Can I infer a JSON Schema from YAML sample data?

For the documented YAML subset, convert values with [YAML to JSON](/yaml-to-json), inspect its type-change warnings, then paste the resulting JSON here. This is a manual two-tool workflow, not direct YAML input. It infers constraints from sample values; it does not translate a YAML schema or OpenAPI contract into JSON Schema.

JSON to JSON Schema

Paste one JSON sample to infer a JSON Schema, then review types, required fields and array items before using it as a contract. An object or API response can be a starting point; an array of sample records reveals fields that vary between records. Choose Draft 2020-12 or Draft-07, optional format and enum inference, and compact or indented output. Inference runs in your browser.

sample.json

schema.jsondraft 2020-12

The inferred schema appears here.

Draft

Required

Detect formats

Detect enums

Indent

Detected

The current specification. Use this unless a tool demands otherwise.

Formats are detected, not guessed at random. A string matching an email, a UUID, an ISO date or a URI gets the matching format keyword; anything ambiguous stays a plain string rather than over-constraining your schema. The same care decides required: across a list of objects a key is only required when every single sample had it, so the schema always validates the document it came from.

Common questions

How does it decide which keys are required?: For a single object, every key present is marked required by default, and you can switch that off. For an array of objects the rule is stricter and more useful: required is the intersection of keys present in every element, while properties is the union of all keys seen anywhere. A key that appears in some records but not others is therefore an optional property, which is almost always what you meant.
Which string formats does it detect?: Conservative, high-confidence ones: email, uri, uuid, date, date-time, ipv4 and ipv6. Detection is deliberately cautious. A string that merely could be a date is left as a plain string rather than constraining your schema to a format your real data may violate. Over-tight inferred schemas are worse than loose ones because they fail on valid records later.
What happens with mixed-type arrays?: The item schemas are unified into a single type union: an array holding a number, a string and a boolean produces items with "type": ["integer", "string", "boolean"], which is compact and valid in both drafts. For an array of objects with differing keys, required becomes the intersection of keys present in every element while properties is the union of every key seen, so a key that appears in only some records is correctly optional. Empty arrays produce an unconstrained items schema, because a sample of zero elements tells you nothing about what belongs in them.
How are null values handled?: A key whose only observed value is null is typed as null. A key seen as both null and something else becomes a union of the two types, which is the correct reading of nullable data. This matters because the naive alternative (treating null as "no information" and dropping it) produces a schema that rejects the very document it was generated from.
Which draft should I use?: Draft 2020-12 is current and the right default for new work. Draft-07 is offered because a great deal of tooling (older validators, some code generators and several API frameworks) has not moved on. For the schemas this tool emits the two outputs are identical apart from the $schema URI they declare, so switching is safe and you can pick whichever your validator expects.
Is my JSON uploaded anywhere?: No. Inference runs entirely in your browser, which is the point: the sample document you want a schema for is usually a real API response or a production record, and those routinely contain customer data. There is no request to inspect because there is no server to send it to.
How do I generate a JSON Schema from an array of objects?: Paste the whole array as one JSON value. For [{"id":1,"name":"A"},{"id":2}], the item schema includes id and name but requires only id: it appears in every record. Properties are the union of observed keys, and required is their intersection. An empty array has no observed item constraints. Include representative records, not only the easiest example.
What do format and enum detection add?: Format detection adds a recognized string format only when every observed string at that location matches it. Enum inference uses small repeated string sets; a few examples can over-constrain future values, so switch it off when the sample does not represent every allowed value. The adjacent validator treats format as annotation and does not assert it.
Can I validate the generated schema against my sample?: Copy a Draft 2020-12 result into [JSON Schema Validator](/json-schema-validator) and paste the sample as the instance. Review that validator’s unchecked-keyword notices. It supports a bounded set of 2020-12 constraints; a Draft-07 output needs a validator that supports that dialect. Passing the sample still does not prove that the inferred schema describes all future records.
Can it generate JSON data from a schema, classes, forms or documentation?: This page performs sample-to-schema inference only. It does not reverse a schema into example or test data, generate forms, diagrams, database schemas, documentation, Avro or protobuf contracts. For Dart classes or TypeScript types from supported JSON or JSON Schema, use [JSON to Dart and TypeScript](/json-to-code). That generator does not turn every schema constraint into a type assertion.
Is JSON Schema the same as JSON-LD, schema.org or OpenAPI?: No. JSON Schema describes constraints on JSON values. [Schema Markup Generator](/schema-markup-generator) builds JSON-LD for its four supported schema.org types. An API response sample does not contain the paths, operations and parameters needed to construct an OpenAPI contract. This page also does not translate XSD, Zod, YAML schemas or language classes into JSON Schema. To reserialize an existing JSON Schema document as YAML values, use [JSON to YAML](/yaml-to-json/json-to-yaml); its keywords remain values rather than being translated into another schema language.
Can I infer a JSON Schema from YAML sample data?: For the documented YAML subset, convert values with [YAML to JSON](/yaml-to-json), inspect its type-change warnings, then paste the resulting JSON here. This is a manual two-tool workflow, not direct YAML input. It infers constraints from sample values; it does not translate a YAML schema or OpenAPI contract into JSON Schema.

The schema describes the sample you gave it. Inference cannot see fields your sample omits, so review the output before treating it as a contract.