Generate a JSON Schema from JSON

A JSON Schema is a JSON document that describes the shape of other JSON documents. It declares what type each value should be, which properties are required, how arrays and nested objects are structured, and which string formats or value constraints apply. Draft-07 is one of the most widely supported dialects, understood by validators in virtually every language, which is why this generator targets it.

Schemas are built from a small vocabulary of keywords. type sets the JSON type (object, array, string, number, integer, boolean, or null); properties maps each object key to its own schema; required lists the keys that must be present; items describes array elements; format annotates strings like email or date-time; and enum, const, minimum, and pattern pin values down further. Because a schema is itself JSON, it lives in your repository and diffs cleanly.

Once you have a schema you can do more than validate. JSON Schema underpins OpenAPI request and response bodies, drives form generation, feeds code generators that emit types, and serves as living documentation of an API contract. Generating one from a real payload is usually the fastest way to bootstrap all of that.

The generator walks your sample recursively. For each value it emits a type: numbers are split into integer or number, strings are pattern-matched against a small set of known formats (date-time, date, time, email, uuid, uri, and IPv4/IPv6), and objects become a properties map plus a required array. Arrays are handled by inferring a schema for every element and, when the elements agree, merging them into one items schema; when they differ, it falls back to oneOf branches, and an empty array yields an open items of {}.

That process is deterministic, so it never hallucinates a field and never varies run to run. But a single example is not the whole domain, and the algorithm only reports what the evidence shows. It marks every present, non-null key as required — almost always stricter than reality — and it cannot infer enums, numeric ranges, string length or pattern, or which fields are genuinely optional.

Format detection is a heuristic and can produce false positives: a dotted numeric code shaped like 203.0.113.5 is tagged as an ipv4 address, and any token with an @ and a dot can trip the email format even when it is not really an email. When two array elements are objects with overlapping keys, the merge marks a key required only if it appears in both, which is a useful signal that a field is optional. Knowing these rules tells you exactly what to double-check in the output.

Once you have a schema, apply it to the Schema panel to check documents against it. This is different from syntax validation: RFC 8259 validation only confirms that text is well-formed JSON, whereas schema validation confirms that a well-formed document also has the right types, required keys, and formats. A payload can be perfectly valid JSON and still violate your schema.

The same schema travels anywhere. Drop it into CI with a validator such as ajv (JavaScript) or python-jsonschema to catch contract drift before it ships, embed it in an OpenAPI definition so request and response bodies are enforced, or use it to power client-side form validation. The $schema keyword at the top declares the dialect so each validator selects the correct ruleset.

The main tuning knob is the required array. Keep it tight enough to catch genuinely missing fields, but loosen it for anything that is legitimately optional — otherwise every request that omits an optional key will fail validation. Because the generated required list is deliberately strict, this is usually the first thing to review.

Treat the generated schema as a first draft that captures structure, then encode the rules only you know. The most common refinements are concrete: remove optional fields from required, add enum or const for values that come from a fixed set (a status field, a set of roles), and add minLength, pattern, minimum, maximum, or multipleOf wherever you have real bounds instead of leaving a bare string or number.

Tighten the edges the sample could not reveal. Replace the open items of {} that an empty array produced with a real element schema, delete any format that was a false positive, and add additionalProperties: false when you want to lock the object to exactly the keys you defined. Adding title and description keywords turns the schema into documentation as well as a validator.

For descriptions specifically, the Schema + Describe Copilot action generates the base schema with the same deterministic algorithm and then uses AI to add human-readable description fields, which is handy when the schema doubles as API docs. Keep the finished schema in version control, and when your payload changes, regenerate from a fresh sample and diff the two to see exactly what moved.