JSON Schema Generator
Generate a strict JSON Schema for LLM structured output, with required fields, enums and nested objects. Draft-07 and 2020-12.
Step 1 — Define fields
Add fields that the LLM should return. Each field becomes a JSON Schema property.
Step 2 — Preview & generate
How it works
- Add fields with names, types, and optional descriptions.
- Choose types: string, number, boolean, array, object, or enum.
- Mark fields as required or optional.
- Generate a JSON Schema Draft-2020-12 compatible schema.
- Use with OpenAI
response_formator Anthropic structured output.
LLM integration example
OpenAI (Python)
from openai import OpenAI
import json
client = OpenAI()
completion = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Get user info for alice"}],
response_format={"type": "json_schema", "json_schema": {
"name": "user_schema",
"schema": {...}
}},
)
result = json.loads(completion.choices[0].message.content) Anthropic (Python)
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=1024,
messages=[{"role": "user", "content": "Get user info for alice"}],
response_format={
"type": "json_schema",
"json_schema": {
"name": "user_schema",
"schema": {...}
}
},
) About JSON Schema Generator
JSON Schema is a declarative format that describes the structure of JSON data — which fields are required, what types they have, and how nested objects are shaped. It plays a central role in LLM structured output: providers like OpenAI and Anthropic accept a JSON Schema in their response format or function-calling APIs to force the model to return valid, predictable JSON. This generator builds such a schema from simple field definitions.
Use it whenever you need reliable JSON back from a language model — for example, turning free-form responses into typed data your code can parse without error handling. A few notes: keep the schema strict but minimal (overly complex schemas can hurt model compliance), mark genuinely optional fields as optional, and test your schema with the built-in validator before deploying it in production.
A field list, not a parsed sample
Despite the name, this page does not infer a schema from a JSON document. You build a list of fields — name, type, optional description, required checkbox, enum values — and the generator emits an object schema from that list. The root is always `type: object` with your fields as `properties` and a `required` array holding only the fields you marked. Fields with an empty name are skipped silently.
Each type expands to a fixed shape. `string`, `number` and `boolean` map across directly; `array` becomes an array with `items: { type: "string" }` hard-coded, so element types must be edited by hand; `object` becomes an object with empty `properties` and `required` arrays; `enum` becomes a string with an `enum` array split from your comma-separated input. There is no `integer`, no `null`, and no way to nest one field inside another from the UI.
Reading the generated document
The schema declares `$schema` as draft 2020-12 and carries a `name` field, which is the identifier OpenAI-compatible endpoints expect alongside the schema itself. A top-level `description` is added as the model-level hint. Empty `description` and `required` values are omitted from the output entirely rather than emitted as nulls, so a schema with nothing required has no `required` key at all.
Duplicate field names are not detected: the second assignment overwrites the first in `properties`, while both names still land in `required`. Give every field a distinct name if the schema is going to be enforced somewhere downstream, and note that field order in the list is preserved in the emitted `properties` object.
The inline validator is not a general engine
The Validate step next to the output is a purpose-built checker rather than a JSON Schema implementation. It confirms the payload is an object, that every key named in `required` is present, that each declared property has the declared primitive type, and that `enum` members are respected. It does not check nested objects, numeric bounds, string formats, array element types, or unexpected additional properties.
So passing it is a weaker guarantee than the schema printed beside it, and much weaker than what a real validator would tell you. For draft 2020-12, 2019-09 and draft-07 validation against an arbitrary schema, the JSON Schema Validator elsewhere on this site runs the real thing.
One structural caveat for LLM use: because optional fields stay out of `required` and `array` is fixed to string items, a model is free to omit what you expected and free to return objects where you described strings. Handle both in code rather than assuming the schema constrains them.
Next steps
- JSON Schema Sample Data— generate test data
- JSON Schema Validator— verify it works
Frequently Asked Questions
How do I generate a JSON Schema from JSON?
What JSON Schema draft does this support?
Can I generate sample data from a schema?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.