JSON to JSON Schema
Paste a sample JSON document and get a JSON Schema inferred from it: types, required keys, nested structures, array item schemas and string formats. Draft 2020-12 and draft-07, no size limit, and the document never leaves your browser.
schema.json
The inferred schema appears here.
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.
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.