Practical example
Validate {"age":"18"} against a schema requiring an integer. The JSON is syntactically valid, but the string still violates the API contract.
type, required, properties, itemsenum, minLength, minimumadditionalProperties: falsetype: ["string", "null"]A JSON Schema Validator / Generator helps you create JSON Schema from sample JSON and validate JSON data against an existing schema.
This is useful for API contracts, backend validation, testing structured responses, and documenting expected payload formats.
Mark fields as required only when every valid payload must include them. Optional fields are better for phased API rollouts and partial responses.
Use additionalProperties false when unexpected fields should fail validation, but avoid it when clients may send forward-compatible metadata.
Represent nullable fields explicitly with type arrays such as ["string", "null"] so null is not confused with a missing field.
Add enum, minimum, minLength, and similar constraints after generation to make the schema closer to the real business contract.
You can also edit the generated schema manually. This version supports common rules such as type, required, enum, minLength, minimum, nullable types, array items, and additionalProperties.
{
"type": "object",
"required": ["name"],
"properties": {
"name": {
"type": "string",
"minLength": 2
},
"age": {
"type": "integer",
"minimum": 18
},
"status": {
"type": "string",
"enum": ["active", "disabled"]
},
"nickname": {
"type": ["string", "null"]
}
},
"additionalProperties": false
}
Learn the workflow behind this tool and what to check next.
A schema workflow that treats successful and failing payloads as executable documentation rather than relying on one ideal sample.
A repeatable workflow for separating transport errors, JSON syntax problems, and data-contract failures in API responses.
A practical workflow for formatting JSON, finding syntax errors, validating payload shape, and checking response status when API data looks wrong.
Use schema validation to make payload assumptions explicit before they become frontend bugs, backend edge cases, or integration failures.
Confirm which fields must exist, which can be omitted, and which can be null without breaking consumers.
Check arrays, objects, numbers, enums, dates, and string formats against the exact shape your application expects.
Compare sample responses against the schema after API changes, vendor upgrades, or webhook version changes.
Use validation paths to find the exact property that failed instead of scanning a large payload manually.
Validate {"age":"18"} against a schema requiring an integer. The JSON is syntactically valid, but the string still violates the API contract.
oneOf, anyOf, nullable fields, and additionalProperties can produce surprising results when overlapping schemas accept the same value.
I keep representative failing payloads beside the schema because error cases expose contract ambiguity faster than a perfect sample.
You may also find these tools useful.