JSON Schema Generator

What a generated schema can and cannot know

Inference from an example is a starting point, not a finished specification. The tool can see that a field holds the string "2026-09-18"; it cannot know whether that field must always be a date, whether an empty string is acceptable, or whether the field is optional in documents you have not shown it.

What it gets right: the shape. Types, nesting, which fields exist, what array items look like, and — when an array of objects is provided — the union of fields across all of them, so a field present in only some records is still described.

What you should add by hand afterwards: formats ("format": "email", "date-time", "uri"), numeric bounds, string patterns, minimum array lengths, and descriptions. Descriptions matter more than people expect — for validation they are documentation, and for LLM structured output they are instructions the model actually reads.

Schemas for LLM structured output

The fastest-growing use of JSON Schema is constraining what a language model returns. Every major provider now accepts a schema and guarantees the response conforms to it, which removes an entire class of parsing failures. The schemas those APIs accept are more restricted than general JSON Schema, and strict mode here produces output that satisfies the common requirements.

The usual constraints: every object needs "additionalProperties": false, every property must appear in the required array, and several keywords — minLength, pattern, format, oneOf at the root — are either unsupported or restricted. Optional fields are expressed by allowing null in the type union rather than by omitting the field from required.

Two pieces of practical advice. Keep schemas shallow: deeply nested structures measurably reduce output quality, and flattening usually costs nothing. And write a real description on every field — that text is the clearest channel you have for telling the model what you actually want in it, and it works better than adding another paragraph to the prompt.

Required fields, nulls and the choices that matter

Two decisions make most of the difference between a schema that helps and one that causes friction.

Which fields are required. Marking everything required catches missing data immediately, which is right for internal data you control. For a public API it is usually too strict — a client omitting an optional field gets a validation error for something harmless. Generate with everything required, then remove the genuinely optional ones from the list.

How nulls are handled. A null in your sample is ambiguous: it might mean the field is nullable, or that your sample happened to have no value. This tool types a null field as ["null", "string"] where it can infer a second type from sibling records, and as the bare "null" type where it cannot — which is almost certainly not what you want, and is deliberately obvious so you notice and fix it.

If you have several sample documents, paste them as an array. Inferring from ten records produces a far better schema than inferring from one, because optional fields and varying types become visible.

How to use the JSON Schema Generator

1. Paste a representative JSON sample

   An array of several records gives a much better schema than a single object, because it reveals which fields vary and which are always present.

2. Choose your mode

   Standard for API validation. Strict for LLM structured output and function calling, which adds additionalProperties: false and requires every field.

3. Review the required list

   Everything present in the sample is marked required by default. Remove the fields that are genuinely optional.

4. Add formats and descriptions

   Copy the schema into your editor and add format, bounds and a description for each field. The descriptions are what a model reads.

Frequently asked questions