How to use this tool
- Paste JSON or load a local JSON file, up to 1 MiB.
- Choose whether observed properties should be required.
- Generate a schema, validate another sample and export schema.json.
Infer and validate a small JSON contract
Generate a starting schema for a sample API record, then decide which observed fields are true business requirements.
Input
{"id":1,"nickname":null}Expected output
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"id": {
"type": "integer"
},
"nickname": {
"type": "null"
}
},
"required": [
"id",
"nickname"
]
}With required-by-default on, both observed fields are required. The sample {"id":2,"nickname":null} passes; {"id":"2","nickname":null} fails because id is a string. One null value does not prove that nickname can never be a string. This is Draft 2020-12 inference, not a complete domain model.
More examples
- 42 infers integer; 42.5 infers number.
- [1, "one", null] produces anyOf for mixed array items.
- An empty array infers unconstrained items; it cannot reveal the intended element type.
Know the limits
Inference describes observations, not business requirements. Review required fields, enums, ranges, formats and additionalProperties yourself. Validation here applies to the generated schema.
Common questions
Can it infer email format or business rules?
No. One string is insufficient evidence of a format or contractual rule.
Are prototype-named keys allowed?
Yes. They are handled as literal data properties, not merged into prototypes.