Optional and nullable fields
For [{"id":1,"email":null},{"id":2}], id is required; email is optional and has type null. Add a string example to allow string emails.
Build a reviewable schema from an example response or fixture. The generator combines array samples, distinguishes missing fields from null values, and writes a real Draft 2020-12 schema document.
149 / 500,000 characters. Processing stays in this browser.
Array items are merged as samples. A property is required only when it appears in every sampled object at that location. Null stays a separate allowed type, and different types use anyOf. Empty arrays leave items unconstrained.
This schema describes observed shapes. It does not infer a complete API contract, string formats, enums, ranges, or every possible optional field. Review required and additionalProperties before using it to validate production data.
All parsing and exports run locally in your browser. Example records are original fictional data, not an external dataset.
Paste one valid JSON value. Put multiple record examples in an array.
Optionally give the schema a title and decide whether extra object properties should be rejected.
Generate the schema, review its required fields and unions, and download schema.json.
For [{"id":1,"email":null},{"id":2}], id is required; email is optional and has type null. Add a string example to allow string emails.
[1, 2.5, "unknown"] produces array items that allow numbers or strings. An empty array produces an unconstrained items schema.
Object examples at the same array-item location are merged. A key becomes required only if it exists in every observed object there. Null is a present value, not an absent key. Nested objects follow the same rule independently. A single object therefore makes all of its observed keys required.
A value that looks like an email does not establish an email contract. The generator deliberately omits inferred formats, enums, minimums, maximums, and length limits. It also leaves additional properties allowed unless you enable the explicit closed-object option. That option applies recursively and may be too strict for evolving APIs.
JSON numeric tokens are examined without converting them to floating-point numbers. Whole mathematical values, including 1.0 and 2e3, infer integer; fractional values infer number. When both occur at one location, number includes both. Duplicate object keys are rejected rather than silently overwritten.
No. It describes the shapes in your examples. Review it against real requirements and validate more representative data before adopting it.
Draft 2020-12. The output declares https://json-schema.org/draft/2020-12/schema in $schema.
There are no observed property constraints. Enable rejection of additional properties only when an empty object must truly remain empty.