JSON to JSON Schema Generator & Validator
Generate a JSON Schema from one or many JSON samples, with the sample counts behind each required field. Documents are validated against it as you type.
The format keyword is recorded as an annotation and not checked (the 2019-09 and 2020-12 default). Turn on Assert formats to reject values that do not match.
Paste samples to generate a schema, or paste your own schema in the editor to check documents against it.
About JSON to JSON Schema Generator & Validator
A JSON Schema generator is only as good as the samples it sees. Turning JSON into JSON Schema from one document means every field comes out required, because a single sample cannot show that a key is sometimes missing. Paste several instead: a root array, an NDJSON log, or documents one after another. They are merged into one schema, and each property's required status comes from counts you can read, such as "present in 5 of 7 samples".
The schema appears as you type and is checked straight away against every sample it came from. Edit it and the check runs again. Paste a schema of your own and the page works as a JSON Schema validator for any document: each error is reported as a JSON Pointer plus a line and column, and clicking it takes you to the spot.
Output defaults to draft 2020-12, the dialect OpenAPI 3.1 uses, with 2019-09 and draft-07 one click away. Repeated shapes go under $defs (definitions in draft-07), and nullable fields are written the way each draft expects, including around a $ref. In 2019-09 and 2020-12 the format keyword is an annotation unless you turn on assertion, and the page notes when formats are recorded but not checked.
This free JSON Schema generator needs no signup. Generation runs in the page and validation runs in a Web Worker in the same tab, so a payload carrying tokens or customer records is never uploaded. A remote $ref is never fetched. For TypeScript, Go, or Zod types, use the JSON to TypeScript converter instead. Is the JSON itself malformed? Fix it in the JSON Formatter.
How to use the JSON Schema generator
- Paste one JSON document or several: a root array, NDJSON (or JSONL), or documents one after another. You can also drop a .json, .ndjson, or .jsonl file. The Root array control decides whether a top-level array is a list of samples to merge or one document to describe, so you can build a JSON Schema from a JSON array either way.
- Pick a draft: 2020-12 (the default, and what OpenAPI 3.1 uses), 2019-09, or draft-07. The $schema URI and the definitions keyword follow the draft.
- Pick the required rule and read the Evidence tab. Each property shows how many samples had it, so you can see why a field was inferred as required or optional.
- Set the options: reuse repeated shapes as $defs, disallow extra properties (additionalProperties: false on every object), detect formats such as date-time and email, include examples taken from your samples, and add a title.
- Read the self-check in the output header. Every sample is validated live against the schema. A failing one lists each error with its JSON Pointer, line, and column, and clicking an error jumps to it.
- Open the Test document tab to validate JSON against the schema without changing it. To validate several JSON files against the schema, paste their contents one after another (or as NDJSON) and each document is checked separately.
- Edit the schema directly, or paste your own to use the page as a JSON Schema validator. Reset to generated brings back the inferred schema. Copy it formatted or minified, or download schema.json.
Common Use Cases
An OpenAPI 3.1 component from a real response
OpenAPI 3.1 schemas are JSON Schema 2020-12, so paste a few responses from the endpoint, check the required list against the evidence, and move the result into components/schemas. Turn off Reuse repeated shapes first, or rewrite each "#/$defs/X" to "#/components/schemas/X": inside an OpenAPI document, a "#/..." reference in a schema with no $id of its own resolves against the document root, where there is no $defs. Nullable fields already use the 2020-12 form, so there is no nullable: true to translate.
Pin down an NDJSON or JSONL feed
Paste a slice of the log and each record counts as a separate sample, merged into one schema. Fields that only some records carry come back optional, with their counts, and a field that switched between a string and null is written as a type array. Going from NDJSON to JSON Schema this way describes the whole feed, not its first line.
Check a payload before it ships
Keep the schema in the editor and paste the new document in the Test document tab to validate the JSON against the schema. Then fix what the errors point to. A missing required property points at the object that lacks it, and a property that is not allowed points at the property itself.
Tool and structured-output definitions for LLMs
Generate the argument schema from a handful of example calls, turn on Disallow extra properties (additionalProperties: false) so the model cannot invent keys, then tighten it by hand with enums, bounds, and descriptions.
Frequently Asked Questions
Can I generate a JSON Schema from multiple JSON samples?
Yes. Paste a root array, NDJSON or JSONL with one document per line, or several documents one after another, and Auto detection tells them apart. Every sample is merged into one schema: keys are combined, a key that held a string in some samples and a number in others gets both types, and required is decided from counts. A count such as "present in 5 of 7 samples" means the key was missing from two samples, so it stays out of the required list. The Evidence tab shows that line for every property.
How do I make a field optional in JSON Schema?
There is no optional keyword. A property is optional unless its name is listed in required, so leave it out of that array: with "required": ["id", "name"], every other property may be absent. Required means the key must be present. It says nothing about the value, so a required key can still hold null if its type allows it.
How do I allow null in JSON Schema?
For a simple type, list both: "type": ["string", "null"]. Around a $ref, wrap it: "anyOf": [{ "$ref": "#/$defs/Address" }, { "type": "null" }]. Adding null beside the $ref does not work: draft-07 ignores keywords beside $ref, and 2019-09 and later apply them as extra constraints, so neither can widen a $ref to also allow null. anyOf with a null branch does. Null is not the same as absent: null is a value the key holds, while an optional key may be missing altogether. OpenAPI 3.0's nullable: true is not part of JSON Schema. Many validators ignore it, while Ajv (which this page uses) accepts it as an extension when type is present. Portable JSON Schema uses a type array or anyOf with null. The JSON Schema Keywords by Draft reference has a table of these cases.
What is the difference between draft-07 and 2020-12, and which should I use?
Most of the gap opened in 2019-09: definitions became $defs, keywords beside $ref started to apply, and unevaluatedProperties and unevaluatedItems were added. 2020-12 then moved tuples from array-form items to prefixItems and replaced $recursiveRef with $dynamicRef. Use 2020-12 for new work and for OpenAPI 3.1. Use draft-07 when your validator, framework, or tooling only supports it.
Is the format keyword validated?
Not by default. In 2019-09 and 2020-12 the format keyword is an annotation: it records intent, and a validator checks it only when configured to. Draft-07 left it to the implementation. The Assert formats switch (off by default) shows both behaviors, so you can see whether an email or date-time value would be rejected by a validator that does check formats.
How do I find where a JSON Schema validation error is in my document?
Each error carries a JSON Pointer such as /orders/0/qty. This page maps that pointer back to the sample or test document it came from, and to the line and column where the value starts, then jumps there when you click the error. A missing required property points at the object that lacks it, since the missing key has no position of its own.