Short answer
- A generated JSON Schema is a draft based on the examples you paste.
- The generator can infer object properties, arrays, and basic JSON types.
- You still need to review required fields, nullable values, enums, formats, ranges, and application rules.
Safe workflow
- Format the JSON first so syntax errors are easier to spot.
- Generate a starter schema from representative examples.
- Review the schema manually before using it as a validation contract.
- Generate TypeScript types separately when you need application model code.
What can be inferred
| Example JSON | Likely schema inference | Review manually |
|---|---|---|
| "Ada" | string | Minimum length, pattern, allowed values |
| 42 | integer or number | Minimum, maximum, units, precision |
| true | boolean | Whether false is allowed |
| [1, 2, 3] | array of numbers | Item limits and mixed item types |
| {"id":1} | object with properties | Required fields and additional properties |
Required fields
A generator can mark fields required when they appear in every object in the pasted sample. That is a useful starting point, but it is not proof that the field is required in the real API.
If your sample array is small, a field may look required only because the sample did not include enough variations.
Additional properties and strict objects
JSON Schema uses additionalProperties to decide whether an object may contain fields that are not listed under properties. Keeping it true is safer when examples are incomplete or APIs may add fields over time.
Set additionalProperties to false only when the real contract should reject unknown fields. Apply that decision deliberately at each nested object level; one sample cannot prove that unseen fields are invalid.
| Setting | Behavior | Good fit |
|---|---|---|
| true | Allows fields missing from the example | Evolving APIs, partial samples, flexible payloads |
| false | Rejects fields not declared in properties | Strict contracts, controlled configuration, typo detection |
JSON Schema vs TypeScript
JSON Schema is useful for validation contracts and documentation. TypeScript types are useful for application code and editor feedback.
The two can describe similar shapes, but they are not interchangeable. Keep validation rules in the schema and code-facing model details in TypeScript.
FAQ
Can a JSON Schema generator know every allowed value?
No. It can infer structure and basic types from examples, but allowed values, ranges, formats, and business rules need manual review.
Should every object property be required?
Not necessarily. Mark fields required only when the real data contract requires them, not just because they appeared in one sample.
Should I format JSON before generating a schema?
Yes. Formatting first makes syntax problems and nested structure easier to review before schema generation.
Should additionalProperties be false?
Only when the real contract should reject unknown fields. Leave it true when your example may be incomplete or the payload can evolve.