JSON Schema Validation: Required Fields, Types, and Common Errors

Separate properties from required

The properties keyword describes rules for keys when they exist. It does not make them mandatory. Put mandatory key names in the object's required array.

{
  "type": "object",
  "properties": {
    "email": { "type": "string" }
  }
}

{
  "type": "object",
  "required": ["email"],
  "properties": {
    "email": { "type": "string", "format": "email" }
  }
}

Model types exactly

JSON distinguishes strings, numbers, integers, booleans, nulls, arrays, and objects. A quoted number is a string. If null is legitimate, declare a union such as type: ["string", "null"].

Use additionalProperties deliberately. Setting it to false catches unexpected keys, but it also makes contract evolution stricter.

Read errors from the instance path outward

The instance path identifies the data that failed. The schema path identifies the rule. Start with the instance path, compare the actual value and expected keyword, then decide whether the data or the contract is wrong.

1. Validate the JSON syntax independently.
2. Validate the schema syntax and confirm its declared draft.
3. Fix required and type errors before dependent format or range errors.
4. Retest representative valid and invalid examples.

Use formats for interoperable strings

Formats such as date, date-time, email, hostname, and URI add semantic checks to strings. They are useful at system boundaries but do not replace application-specific rules.

UtilityDock evaluates the supplied document and draft-07 schema locally, collects all detected errors, and never changes either input.

Common questions

FAQ