PRACTICAL REFERENCE

A sample is not a data contract

Schema inference gets a draft started. Business constraints need evidence beyond one example.

Separate observation from intent

A sample value of 42 supports an integer observation; 42.5 requires number. A string does not establish whether the intended value is an email address, UUID, country code or free text. Inferring those formats automatically can create surprising validation failures.

The generator chooses Draft 2020-12 and describes the types it sees. Required-by-default means observed object keys become required. It does not mean a product owner has decided those fields must always be present.

Sample: {"id": 1, "nickname": null}
Observed types: id → integer; nickname → null
Unknown: whether nickname may also be a string

Arrays reveal only what they contain

An empty array tells the tool nothing about future elements, so its items schema is unconstrained. Mixed arrays use anyOf across distinct inferred schemas. Arrays of objects can consequently produce several object alternatives rather than a universal model of all possible rows.

The validator on this site interprets the vocabulary generated here without executing code. It validates another sample against that inferred structure. It is not a general arbitrary-schema editor, remote reference resolver or substitute for testing a final schema with your production validator.

Review before making it authoritative

Add justified ranges, lengths, enums, format behavior and a deliberate additionalProperties policy. Decide whether null means “unknown,” “absent” or a valid domain value. Check optional fields across a representative fixture set, not just the first successful response.

Local input is limited to 1 MiB, 32 levels of nesting and 20,000 inference nodes. These bounds prevent accidental browser lockups. Prototype-named properties remain literal JSON data; inference does not merge them into application objects.

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.

Keep the references close

Primary documentation supports the technical details above. Check it alongside the behavior of your own runtime and deployment.

JSON Schema Draft 2020-12 ↗

Open JSON schemas →