JSON Schema Generator

What a JSON Schema is for

JSON itself has no built-in way to say "this field must be a number" or "this object must contain an email key." JSON Schema fills that gap: it is a JSON document that describes the shape of other JSON documents, so a validator can check incoming data against it and reject anything malformed. Writing a schema by hand is tedious and error-prone, especially for deeply nested objects. This tool reverses the work — you paste a representative sample of your data, and it infers a draft-07 schema you can refine. The inference runs entirely in your browser; your sample JSON is never sent anywhere.

How types are inferred

The generator walks your JSON value by value and maps each one to a JSON Schema type. The logic is deliberately specific, and a few cases are worth knowing:

Two refinements add real value. First, whole numbers become integer and fractional numbers become number, so 1 and 1.5 are typed differently. Second, strings are pattern-matched for common formats: a value like "2024-01-15T10:30:00Z" gets "format": "date-time", a plain "2024-01-15" gets "date", an https:// string gets "uri", and an address-shaped string gets "email". Arrays are typed from their first element only.

A worked example

Paste this object:

{ "id": 1, "email": "alice@example.com", "active": true, "score": 98.5, "tags": ["admin"] }

The generator produces a schema whose properties read: id as integer, email as a string with format: email, active as boolean, score as number (because of the decimal), and tags as an array whose items are string — inferred from the first tag. The root carries "$schema": "http://json-schema.org/draft-07/schema#", which tells validators like Ajv (JavaScript) or jsonschema (Python) exactly which dialect to apply.

The two options, and what they actually change

• Make all fields required. By default the schema describes types but marks nothing as mandatory, so a document missing email would still validate. Turn this on and every key in each object is added to a required array, meaning validation fails if any field is absent.
• Add descriptions. This inserts a human-readable description on each property — for object members it uses the key name, as in "description": "The email field". These are placeholders meant to be edited into real documentation, not final prose.

Practical tips

• Feed a complete sample. The schema can only describe fields it sees. If your real data sometimes includes an optional phone field, include it in the sample or the generated schema will not mention it.
• Watch array items. Because only the first array element is inspected, a mixed array like [1, "two"] yields an integer items schema. If your arrays are heterogeneous, you will need to widen the generated items to use anyOf by hand.
• Tighten the schema after generating. Inference gives you a correct starting point, not a strict contract. Add minLength, minimum, enum, or pattern constraints where your domain requires them.
• Decide on required carefully. Marking everything required is convenient but brittle for evolving APIs. For payloads where fields come and go, leave the toggle off and add only the truly mandatory keys yourself.

Common mistakes

• Assuming format strings are validated by default. In draft-07, format is annotation-only unless your validator is configured to enforce it. Setting format: email does not guarantee the validator rejects bad addresses — enable format assertion in your library if you need that.
• Trusting type from a single number. A field that happens to be 10 in your sample is typed integer, but if it can also be 10.5 in production, change it to number manually, since integer would reject the decimal.
• Pasting invalid JSON. The tool parses with the strict JSON grammar, so trailing commas, single quotes, or unquoted keys throw an error. Run your sample through a JSON formatter first if you are unsure.
• Mixing schema drafts. This generator targets draft-07. If your tooling expects draft 2020-12, some keywords differ; check compatibility before deploying.

Where generated schemas pay off

A schema generated from a sample is most useful as scaffolding: validating request and response bodies in an API, documenting a data contract for a frontend team, generating typed models with code-generation tools, or gating data into a pipeline. Starting from your real data means the schema already matches reality — you spend your time tightening constraints rather than transcribing field names.