How to Generate a JSON Schema from Sample JSON

Generation is inference, not contract discovery

A generator can observe object properties, arrays and primitive types in a sample. It cannot know domain rules that are not visible, such as whether a field is optional, which string format is intended or what numeric range is valid.

Treat generated schema as a draft that removes mechanical work. The final schema should express requirements rather than the accidental contents of one payload.

Generate from representative data

One perfect record hides important variation. Include empty collections, optional fields, nulls and realistic value ranges when possible, or compare schemas inferred from several cases.

{
  "id": "usr_42",
  "name": "Asha",
  "age": 33,
  "tags": ["developer", "admin"]
}

Review required fields manually

A generator may mark every observed field as required because every field exists in the sample. That does not prove the API always sends them. Compare the generated list with documentation, producer code and real variants.

Add constraints only when the domain guarantees them

Schema becomes useful when it expresses stable rules. Add formats, patterns, numeric bounds, enums and collection constraints only when they are real contract requirements rather than properties of one example.

• Use format when a field really promises that format.
• Use enum only for a genuinely closed set.
• Use minimum and maximum for real domain bounds.
• Choose additionalProperties behavior intentionally.

Model null, missing and empty separately

A missing property differs from a property set to null, and both differ from empty strings or collections. Decide which states the contract permits rather than deriving semantics from a single observed record.

Validate positive and negative examples

Use JSON Schema Validator with payloads that should pass and deliberate failures that should be rejected. Negative tests prove the schema actually protects the constraints you care about.

Should pass:
{"name":"Asha","age":33}

Should fail if age must be non-negative:
{"name":"Asha","age":-1}

Version schema changes like contracts

Once consumers depend on the schema, removing a field, narrowing an enum or changing a type can be breaking. Keep representative fixtures and validation tests with the schema so future changes can be reviewed deliberately.

Treat generated schema as an inference, not the contract

A generator can only describe evidence that appears in the samples it sees. One integer-looking value does not prove that every future value is an integer; one present property does not prove that the property is required; and one string value does not prove that the field should be an enum containing only that value.

The useful workflow is to generate a baseline quickly, then edit it using knowledge of the real domain. Tighten the schema where the contract is known and deliberately leave room where valid variants exist.

• Use several representative samples rather than one happy-path payload.
• Include nulls, missing optional fields, empty arrays and boundary numbers in the sample set.
• Do not infer enums from accidental repetition unless the allowed set is actually known.
• Review whether additional properties should be accepted or rejected.

Prove the schema with positive and negative fixtures

A useful schema should accept payloads that are intentionally valid and reject payloads that violate the contract. Build a small fixture set around the generated schema before relying on it in CI, API validation or configuration checks.

Negative fixtures are especially valuable because an overly permissive generated schema can appear successful while failing to protect anything important. Remove a required field, change a type, add a forbidden value and test a boundary case so you know which rules are actually enforced.