How to use

Schema Generator

Samples reveal observed structure, not the complete API contract. Review types and required fields before using the generated schema. A top-level array represents multiple samples; wrap an array in an object to describe it as a field.

Use cases

Draft validation rules from API samples
Document nested fields and observed types
Compare required-field assumptions across samples

Is my input uploaded? +

No. Generation and transformation run in a local Worker. Saving a named task is an explicit action that stores data in this browser.

Are previews complete? +

Previews are limited to 60,000 characters. Copy and download request the complete retained output. Input is limited to 1 MiB and generated output to 10 MiB.

Steps and examples

Infer field types without inventing an API contract

A sample reveals what occurred, not every value an API permits. Use several representative records to inspect optional fields and type differences before adopting the generated Draft 2020-12 schema.

How to use this tool

Supply one record or several examples
Paste one JSON object or an outer array of samples. The outer array is a sample collection: the schema describes one record. To describe an array-valued field, put the array inside an object.
Choose required and additional-field policies
The default does not infer required fields. Select common fields as required only when that matches your contract. Leave Allow additional properties enabled unless the examples cover all allowed fields.
Review both schema and field documentation
Generate the preview and inspect union types, required fields and warnings. The field document records observed paths and occurrence counts; choose its language before exporting.

Input and expected output

An optional email that can also be null

Workspace settings: Schema title: User; required policy: I confirm: common fields are required; Allow additional properties: enabled.

Input

[{"id":1,"email":"[email protected]"},{"id":2,"email":null},{"id":3}]

Expected output

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "User",
  "type": "object",
  "properties": {
    "id": {
      "type": "integer"
    },
    "email": {
      "type": [
        "string",
        "null"
      ]
    }
  },
  "required": [
    "id"
  ],
  "additionalProperties": true
}

id occurs in all three samples, so this explicitly selected policy makes it required. email occurs in only two, so it is optional; the observed null is separately retained in its type. An email-looking string does not automatically add format: email.

Limits and checks

Missing evidence is not a constraint: An empty sample list produces an unconstrained schema with a warning. Empty arrays provide no evidence of item types. Formats, numeric ranges and business rules need explicit review; they are not inferred from a few values.
Input shape and inference limits: A standalone scalar such as 42 is rejected. Input is limited to 1 MiB, 1,000 samples, 500 distinct field paths, 48 levels and 25,000 input nodes. These are separate limits, not a promise that every 1 MiB document can be processed.

Understanding the result

Is required the same as non-null?

No. required controls whether a property is present. Its type controls whether null is allowed. A field present with null in every sample can be required and still accept null.

Will sample values appear in the exported documentation?

The schema and field document describe types, paths and occurrence counts rather than embedding sample values. Field names and any title you enter are still included, so review them before sharing.

JSON to Schema & Field Documentation