Infer a JSON Schema from a sample document
Writing a schema by hand for an API you did not design is slow and error-prone. Paste a representative response and this generates a draft 2020-12 schema with inferred types, required properties and nested structure.
- Draft
- 2020-12
- Required
- Inferred from presence
- Output
- JSON Schema
Measured on Apple M4 Max: 0.95 ms infer a schema from a sample (2,000 records) See the benchmarks
How to use it
- Paste a sample document A real API response works best. The more representative the sample, the more accurate the required list.
- Review the inferred types String, number, integer, boolean, null, array and object types are detected, and nested objects become nested properties.
- Copy the schema The schema is emitted as formatted JSON, ready to paste into your validation library or your API documentation.
Questions people ask
Is the generated schema guaranteed to be accurate?
No. It is inferred from one document, so it describes the shape you saw. Treat it as a strong starting point and validate it against several real responses before you rely on it for validation.
How do I mark a property as optional?
A property that is absent from your sample is emitted as optional, and a property that is present in every object is marked required. If you want to force it, edit the generated schema directly.
Which JSON Schema draft is this?
Draft 2020-12, which is the current recommendation. Older drafts use slightly different syntax for references and vocabulary handling, so check what your validation library expects.
Does it handle arrays of objects?
Yes. The schema of the first array element becomes the items schema, and nested objects inside the array are described recursively.
Can I use this with ajv or a Python validator?
Yes, it is a standard JSON Schema document. ajv, jsonschema, pydantic and FastAPI all consume this format, so you can validate it against your own data straight away.
Why does my nullable field look odd?
A field whose value is null is typed as null. If the same field is a string in other responses, the sample needs to include both shapes for the schema to list both types.
Reference
What gets inferred
| Sample value | Inferred type |
|---|---|
| `"id": 42` | `integer` |
| `"ratio": 3.14` | `number` |
| `"active": true` | `boolean` |
| `"deleted_at": null` | `null` (add to the type list) |
| `"tags": ["a", "b"]` | `array` of `string` |
Details that catch people out
A property is marked required because it appeared in the document you pasted. That is a guess about the API, not a fact. If a field is occasionally absent, you need to know that from a second sample or from the documentation before you trust the required list.
If a field is sometimes a string and sometimes an object, a single sample can only show you one of them. Sample each shape separately and merge the results, or edit the generated schema by hand.
Where this earns its keep
Documenting a third-party API
Capture a real response, generate the schema and paste it into the docs. It describes the API that actually returns data rather than the one the marketing page describes.
Adding validation to an existing endpoint
A generated schema gives you a starting point for request validation in your service, and a fixture you can test against.
Writing a TypeScript type
The schema is close enough to a type definition to speed up generating one by hand, and it stays consistent with the JSON it describes.
Last reviewed 2026-10-01. Every tool on DevSnap runs entirely in your browser, so whatever you paste here never reaches a server.