Which JSON Schema draft does it target?

It emits a modern draft that is widely supported by validators like AJV, giving you broad compatibility out of the box.

Are all fields marked as required?

By default, keys present in the sample are treated as required. Since a single sample cannot reveal optional fields, review and relax the required list as needed.

How are arrays handled?

The generator infers a schema for array items from the elements it sees. For arrays of objects, it derives an item schema describing those objects.

How do I generate a JSON Schema from JSON?

Paste a representative sample document and the tool infers a draft JSON Schema describing its types, required fields, and nested structure. Refine the draft, then copy or download it.

Is a generated schema ready to use as-is?

It is a strong starting point. Because a single sample cannot reveal optional fields or precise constraints, review the required list and tighten formats and ranges to match your real rules.

Is my data safe or uploaded anywhere?

Schema inference runs locally in your browser. Your sample data is never uploaded, so it is safe for private payloads.

JSON Schema Generator

Stable

Infer a JSON Schema from a sample JSON document.

Everything is processed locally in your browser

About JSON Schema Generator

The JSON Schema Generator inspects a sample document and produces a JSON Schema that describes its structure, types, and required fields. It gives you a solid starting point for validation instead of writing a schema by hand. Generate the draft, refine the constraints you care about, and use it to validate future data.

Features

Infers types for every property from a sample document
Marks observed keys as required and captures object structure
Describes arrays by inferring the schema of their items
Targets a modern JSON Schema draft for broad tool compatibility
Handles nested objects and arrays to any depth
Editable output so you can tighten constraints after generation

How to use JSON Schema Generator

1
Paste a representative sample
Provide a JSON document that reflects the shape of the data you want to describe.
2
Generate the schema
The tool infers types, required fields, and nested structure into a draft schema.
3
Refine the draft
Adjust required fields, formats, and constraints to match your real rules.
4
Use it for validation
Pair the schema with the JSON Schema Validator to check future documents.

Examples

Sample to inferred schema

Input

{
  "id": 1,
  "name": "Ada",
  "tags": ["a", "b"]
}

Output

{
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string" },
    "tags": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["id", "name", "tags"]
}

How JSON Schema inference works

Inference produces a draft, and it is important to treat it as one

A generated schema describes the example you provided, not the contract you intend. Those coincide only by accident. If your sample has `"status": "active"`, the generator can see that the field is a string - it cannot know that the only permitted values are `active`, `suspended` and `closed`. If `"retries": 3` appears, it infers an integer, not that the valid range is 0 to 5.

Optionality is the biggest gap. Every field in the sample is present, so a naive inference marks everything as required. Fields that are genuinely optional will then fail validation whenever they are legitimately absent, and you will spend a while confused about why valid payloads are being rejected.

The right mental model is that generation does the mechanical 80% - the structure, the nesting, the basic types - and saves you a lot of typing. The remaining 20% is where the schema becomes valuable, and it has to come from knowledge the sample does not contain.

What to add after generating

Start with `required`. Go through the generated list and remove every field that can legitimately be absent. This single edit prevents most of the false rejections people hit with generated schemas.

Then add constraints. `enum` for fields with a fixed value set. `minimum` and `maximum` for numbers with real bounds. `minLength`, `maxLength` and `pattern` for strings with a shape. `format` for the standard ones - `date-time`, `email`, `uri`, `uuid` - which most validators check.

Then tighten the containers. `additionalProperties: false` on objects that should not accept unknown keys turns silent typos into validation errors, which is usually what you want for an API request body. And `minItems` on arrays that must not be empty catches a common class of bug.

Finally, add `title` and `description` to anything non-obvious. Schemas are documentation as much as validation, and many tools generate API reference pages directly from these fields.

Why one sample is rarely enough

A single example cannot show you variation, and variation is what a schema needs to describe. Optional fields do not appear as optional. Nullable fields look like plain types unless the sample happens to contain a null. Union types - a field that may be a string or a number - look like whichever one the sample had.

Generating from several samples that between them exercise the variation is much more effective: a record with all optional fields present, one with none of them, one with nulls where nulls are allowed. Where the inferences disagree, you have found exactly the spots that need a human decision.

Arrays deserve particular care. A generator typically infers the element schema from the first element, so an array of heterogeneous objects will produce a schema that only describes the first kind.

Reference

What inference gets right, and what you must add

Aspect	Inferred?	Action
Structure and nesting	Yes	Usually correct as generated
Basic types	Yes	Check integer vs number
required	Over-inclusive	Remove genuinely optional fields
enum	No	Add for fixed value sets
min / max	No	Add real numeric bounds
pattern, format	No	Add for emails, dates, UUIDs, URIs
additionalProperties	No	Set to false on closed objects
Nullable fields	Only if null appears	Add null to the type union
Array element variation	First element only	Widen with oneOf if heterogeneous

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need a schema and do not want to type the structure by hand: Generate, then refine. This is the intended workflow and it saves real time.
You have a schema and want to check documents against it: The JSON Schema Validator is the other half of the pair.
You only need to know whether a document is well-formed: The JSON Validator answers that without any schema at all.
You want documentation rather than validation: A schema works well for this - add `title` and `description` everywhere and generate API docs from it.

Use cases

Bootstrapping a validation schema from an existing API response
Documenting the expected shape of a config file
Generating a contract for a payload before writing tests
Creating a starting schema for code generation tooling
Standardizing data structures across a team from a known example

Troubleshooting common errors

Valid documents fail validation against the generated schema

Why: Every field in the sample was marked required, including the optional ones.

Fix: Prune the `required` array to the genuinely mandatory fields. This is almost always the cause.

A field typed as integer rejects a decimal value

Why: The sample happened to contain a whole number, so `integer` was inferred rather than `number`.

Fix: Change the type to `number` where fractional values are legal. Prices and rates are the usual victims.

A nullable field rejects null

Why: The sample had a concrete value, so null was never inferred as a possibility.

Fix: Widen the type to `["string", "null"]`, or use `anyOf` on Draft 2020-12.

An array of mixed objects only validates the first kind

Why: Element schemas are inferred from the first element.

Fix: Replace the `items` schema with `oneOf` listing each variant, or use a discriminator field.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Value constraints - enums, ranges, patterns, formats - cannot be inferred from an example.
All sampled fields are marked required, so the `required` list needs manual pruning.
Nullability is only detected if a null appears in the sample.
Array element schemas come from the first element, so heterogeneous arrays are under-described.
Cross-field rules such as "either A or B" are outside what inference can reach.

Frequently asked questions

JSON Schema Validator

Validate JSON against a JSON Schema using AJV.

JSON Validator

Validate JSON syntax and pinpoint the exact line and column of any error.

Online JSON Formatter & Validator

Pretty-print JSON with configurable indentation and instant validation.

JSON to YAML Converter

Turn JSON into clean, readable YAML for configs, pipelines and manifests.

Learn more

How to Generate a JSON Schema from a Sample DocumentWriting a JSON Schema by hand is slow and error-prone. This guide shows how inferring one from a real example gets you a working draft in seconds, plus how to refine it correctly.