Infer a JSON Schema from example JSON
A JSON Schema describes what valid JSON looks like: which properties exist, their types, which are required and which formats strings follow. Writing one from scratch for a large payload takes time. This generator infers a JSON Schema from sample data using quicktype. Every distinct object shape becomes an entry under definitions, and the root refers to it with $ref. The output declares "$schema": "http://json-schema.org/draft-06/schema#".
Example
From the sample below (class name Task):
{
"id": 42,
"title": "Write docs",
"done": false,
"priority": 2.5,
"tags": ["docs"],
"owner": { "name": "Ada", "email": null },
"due": "2026-10-01T09:00:00Z",
"subtasks": [
{ "title": "Outline", "estimate": 2 },
{ "title": "Draft" }
]
}
the generator produces, among others, this definition:
"Subtask": {
"type": "object",
"additionalProperties": false,
"properties": {
"title": { "type": "string" },
"estimate": { "type": "integer" }
},
"required": ["title"],
"title": "Subtask"
}
estimate is missing from one subtask, so it is not listed in required. In the Task definition, id is an integer, priority a number, owner a $ref to #/definitions/Owner, and due a string with "format": "date-time".
What the generator infers
| From the sample | In the schema |
|---|---|
| Whole numbers only | "type": "integer" |
| Any decimal | "type": "number" |
| ISO date-time strings | "format": "date-time" (also date, time, uuid) |
| Nested objects | definitions entries referenced by $ref |
| Keys present in every object | listed in required |
| Values that are sometimes null | anyOf with {"type": "null"} |
Every object is marked "additionalProperties": false, which means extra keys are rejected by validators. That is strict but useful: it catches typos in property names. Relax it by removing the line or setting it to true if your API may add fields.
Top-level arrays
When the sample is an array, the root of the schema is "type": "array" with "items" pointing to a definition named after your class name plus Element. All array elements are merged into that one definition, so the more records you include, the more accurate the required lists and types become.
Refining the schema
A sample shows types, not rules. Consider adding:
minLength,maxLengthandpatternfor strings;minimumandmaximumfor numbers.enumfor fields with a fixed list of values, such as a status.descriptionfor each property, which documentation tools display."format": "email"or"uri"where applicable.
Draft-06 schemas are accepted by the common validators such as Ajv, and can be upgraded to newer drafts (2019-09 and 2020-12) mostly by renaming definitions to $defs and updating $schema.
Uses for a generated schema
- Validating request bodies in an API, or configuration files in CI.
- Editor autocompletion: VS Code validates JSON files against a schema referenced with a
"$schema"property in the file, or mapped to file patterns with thejson.schemassetting, and then suggests property names as you type. - Test fixtures: validating sample payloads in unit tests catches accidental changes to an API's response shape.
- Documentation and contract tests between services.
- Generating code in other languages from the schema.
For TypeScript-native validation, see JSON to Zod. Validate the input first with the JSON Validator, and pretty print the schema with the JSON Formatter if you edit it by hand. Everything runs in your browser.