JSON Schema Builder

How It Works

JSON Schema is a contract for JSON data: it declares which fields an object must have, what type each field is, which ones are required, and what values are allowed. It is the standard way to tell an AI model exactly what shape its answer must take (function calling and structured outputs both consume JSON Schema), to validate API payloads, and to document data formats for other developers. Writing schemas by hand is error-prone — one misplaced bracket or a forgotten required array silently changes the contract — so this builder lets you assemble the schema visually and generates the JSON for you, following the modern draft 2020-12 specification.

Start with Add field. Each field has a name, a type, and three optional extras. The types cover the JSON basics — string, number, integer, boolean — plus the structural ones: object for nested groups of fields, array for lists (with a configurable item type), and enum for strings restricted to an explicit list of allowed values. The required checkbox decides whether the field must be present; required names are collected into the schema's required array automatically. The description is more important than it looks: AI models read descriptions to understand what each field means, so "The city and state, e.g. San Francisco, CA" produces far better function-call arguments than a bare field named location. The default value is recorded in the schema for documentation and for consumers that apply defaults.

Choose object as a field's type and the builder reveals nested sub-fields — an address object containing street, city, and zip, for example, each with its own type and required flag. Nesting can go as deep as your data does. Choose array and you pick the item type: an array of strings for tags, an array of objects for line items. Choose enum and you list the allowed values comma-separated; the validator will reject anything not on the list, which is exactly how you constrain a model to answer "celsius" or "fahrenheit" and nothing else.

The live preview

Every keystroke rebuilds the schema on the right, syntax-highlighted: keys in blue, strings in green, numbers in amber, booleans in pink. What you see is exactly what the Copy button puts on your clipboard — a complete draft 2020-12 schema with $schema, type: object, properties, and required. Paste it directly into an OpenAI function definition, an Anthropic tool definition, a config file, or API documentation. Because it is generated, it is always syntactically valid JSON — the class of bug where a hand-written schema fails to parse simply cannot happen.

The validator

A schema is only useful if you can check data against it. Paste any sample JSON — a real API response, a model's function-call arguments, a test fixture — and the validator walks it against your schema, reporting specific errors: address.zip: expected integer, got string. or missing required field "email". Errors use dot paths for nested objects (address.city) and bracket indices for arrays (items[2].price), so you can find the problem instantly. Validation runs live as you type, with a Validate button for an explicit check. This tight loop — edit the schema, paste a sample, read the errors — is the fastest way to converge on a contract that both humans and models can satisfy.

Worked Example

Let's build the classic get_weather function schema used in AI function calling. Click Load example and the builder creates two fields. The first is location, type string, marked required, with the description "The city and state, e.g. San Francisco, CA". The second is unit, type enum with values celsius, fahrenheit, description "Temperature unit for the response", and default celsius. The preview shows:

properties containing both fields, required: ["location"], and the enum constraint on unit. Copy it into a function definition and the model is now contractually obliged to supply a location every time it calls the function, while unit is optional and can only be one of the two allowed strings.

Now test it. The example pre-fills the sample box with {"location": "Boston, MA", "unit": "fahrenheit"} — the validator reports valid. Change fahrenheit to kelvin and you immediately get: unit: value "kelvin" is not one of ["celsius", "fahrenheit"]. Delete the location line and you get: missing required field "location". Change it to "location": 90210 and you get: location: expected string, got number. Each error tells you the field, the expectation, and the reality — the three things you need to fix the data or the schema.

A nested example

For something richer, build an order schema by hand: a required string order_id, a required object customer with required strings name and email, an array items whose item type is object (note: array-of-object item detail is kept simple here — describe the item shape in the field description), and an enum status with pending, paid, shipped, cancelled. The preview nests customer's properties one level deep with its own required array, demonstrating how the builder composes. Paste a sample order missing the email and the validator pinpoints customer: missing required field "email". — dot-path precision that saves real debugging time.

Tips and Common Mistakes

The most common schema mistake is marking everything required. Required should mean "the data is meaningless without this" — usually one to three fields. Over-required schemas make models fail validation on harmless omissions and make APIs brittle for clients. When in doubt, leave a field optional and document its absence in the description ("omit when unknown").

The second mistake is the number versus integer confusion. Use integer for counts, ages, and quantities — things that are never fractional. Use number for measurements and money. A zip code that looks numeric should be a string, not an integer: leading zeros matter ("02139" is not the number 2139), and nobody does arithmetic on a zip code. The validator enforces the distinction strictly, which is precisely why choosing correctly up front saves debugging later.

Third, write descriptions for models, not just for humans. When a schema is used for function calling, the description is the model's only guidance about what belongs in the field. "string" tells it nothing; "The customer's email address for the receipt" tells it everything. Good descriptions measurably reduce malformed function calls — they are the cheapest reliability improvement in prompt-adjacent engineering.

• Prefer enums over descriptions for fixed choices. "One of: red, green, blue" in a description is a suggestion; an enum is enforcement. Models respect enums far more reliably.
• Keep arrays homogeneous. JSON Schema's items describes one item type. If your list mixes shapes, you probably want an array of objects with an enum "kind" field, not a mixed array.
• Validate real samples, not ideal ones. Paste the ugliest real payload you have — the one with the missing field and the weird null. Schemas tuned on ideal data break on contact with production.
• Version your schemas. When a schema feeds a production API or a deployed agent, treat changes like API changes: additive first, and never rename a field without a migration plan.
• Remember what validation does not do. The validator checks shape and types, not business rules — "email looks like an email" or "end date is after start date" need application code. Use schemas for structure, code for logic.

Schemas and AI function calling in practice

JSON Schema earned its recent fame as the language AI models use to call functions. When you define a tool for a model — get_weather, search_orders, book_appointment — you hand the model a JSON Schema describing the arguments, and the model replies with JSON that must conform to it. This is where every builder feature pays off at once. Required fields guarantee the model cannot "forget" the critical argument. Enums keep free-text fields like units, statuses, and categories inside the vocabulary your code handles. Descriptions teach the model what each argument means, which directly reduces malformed calls. And the validator lets you test the contract before deployment: paste the exact JSON your application expects to receive and confirm the schema accepts it, then paste a few malformed variants and confirm it rejects them with clear errors. Teams that do this loop ship function-calling features with dramatically fewer production incidents, because the most common failure — the model inventing a plausible-but-wrong argument shape — is caught on the workbench instead of in front of users.

Beyond AI, the same schemas document REST APIs, validate configuration files, and generate forms. A schema you design here can be fed to documentation generators that produce human-readable API references, to code generators that scaffold TypeScript interfaces or Python dataclasses, and to test harnesses that fuzz your endpoints with schema-conformant random data. One well-designed contract serves all of these consumers, which is why the hour spent getting the types, required flags, and descriptions right pays for itself many times over. Start strict on the fields your system depends on, stay permissive on the rest, and let the validator — not optimism — be the judge of whether a payload is acceptable.

Everything here runs locally in your browser: your field designs, descriptions, and sample data never leave your device. The generated schema is standard draft 2020-12 JSON, so it works with any compliant validator, documentation generator, or AI provider's function-calling API — no lock-in, no surprises.