How to Validate JSON with JSON Schema

JSON syntax and JSON Schema answer different questions

A JSON parser checks whether quotes, commas, objects, arrays, numbers, booleans, and null values follow JSON syntax. It does not know which properties an API requires or whether a number is within an acceptable range.

JSON Schema describes those expectations. The JSON Schema Validator checks a JSON instance against a supplied draft 2020-12 schema and reports all discovered mismatches with instance paths, keywords, and messages.

Start with a small object schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["name", "active"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0 },
    "active": { "type": "boolean" }
  },
  "additionalProperties": false
}

This schema expects an object. It requires name and active, describes the allowed type and constraints for known properties, and rejects names not listed under properties.

The age property is optional because it does not appear in required. If present, it must be a non-negative integer.

Use type constraints deliberately

JSON Schema distinguishes several core JSON types:

• object for named properties;
• array for ordered items;
• string for text;
• number for any JSON number;
• integer for numbers without a fractional value;
• boolean and null.

A quoted value "2" is a string, not a number. Schema validation does not normally coerce it into another type. This distinction is especially important after converting CSV to JSON, because CSV cells begin as text unless type detection is enabled.

Required does not mean non-empty

The required keyword checks whether an object contains a property. It does not reject an empty string by itself. Add minLength for required text that cannot be empty, minimum or exclusiveMinimum for numeric boundaries, and minItems for arrays that need entries.

Likewise, properties describes constraints for properties when they exist. Put a property name in required when absence is invalid.

Validate arrays and their items

{
  "type": "array",
  "minItems": 1,
  "uniqueItems": true,
  "items": {
    "type": "string",
    "minLength": 1
  }
}

This schema requires at least one non-empty string and disallows duplicate items. For an array of objects, place an object schema under items. Array order remains part of the JSON data even when the schema does not attach a different rule to each position.

Control unexpected properties

By default, an object can contain properties that are not listed under properties. Set additionalProperties to false when the contract should reject unknown fields.

This is useful for catching misspellings and outdated fields, but it also makes a schema less tolerant of future additions. Choose the policy according to the contract rather than enabling strictness automatically.

Reuse definitions with local references

Repeated structures can be placed under $defs and reused with $ref:

{
  "$defs": {
    "identifier": {
      "type": "string",
      "minLength": 1
    }
  },
  "properties": {
    "customerId": { "$ref": "#/$defs/identifier" }
  }
}

The validator resolves references available within the supplied schema document. It does not download remote schemas. Keep required definitions local or combine them into one resolvable document before validation.

Combine alternatives carefully

• allOf requires every listed subschema to pass.
• anyOf requires at least one listed subschema to pass.
• oneOf requires exactly one listed subschema to pass.
• not requires its subschema not to match.

oneOf can fail when no branch matches or when more than one branch matches. Make alternatives distinct with type, required properties, constants, or other discriminating constraints.

Understand format handling

The format keyword can annotate values such as email addresses, dates, or URIs. In this validator, formats are treated as annotations rather than asserted as validation rules. Use explicit constraints such as pattern, length boundaries, or application-level checks when format enforcement is required.

A regular expression can express useful string rules, but it should be designed and tested carefully. Schema validity does not prove that a pattern reflects the business requirement.

Read validation issues by path and keyword

Each issue shows the instance path where the mismatch occurred, the schema keyword that failed, and a message. A root-level problem uses /. A nested issue such as /customers/2/name points to a specific property in an array item.

Start with type errors near the root because one incorrect container can create many downstream messages. Then review required and additional properties, followed by value-level constraints.

Validate JSON against a schema step by step

1. Format both documents. Use JSON Formatter to correct syntax before schema validation.
2. Confirm the draft. Supply a schema intended for JSON Schema 2020-12.
3. Load the instance and schema. Keep them on the correct side of the workspace.
4. Run validation. A valid result means no asserted schema constraint failed.
5. Review issues from broad to specific. Resolve container types and missing structures before smaller value errors.
6. Test boundary examples. Include minimum and maximum values, empty collections, unknown properties, and each alternative branch.
7. Retest in the destination. Application behavior and business rules can extend beyond JSON Schema.

Final JSON Schema checklist

• Both the instance and schema are valid JSON.
• The schema declares or is intended for draft 2020-12.
• Required properties and non-empty constraints are distinguished.
• Strings and numbers use the intended JSON types.
• Array item rules and size boundaries are covered.
• The additional-property policy is deliberate.
• All references resolve inside the supplied document.
• Format annotations and application-specific rules are checked separately.

Open JSON Schema Validator to test the contract. Use JSON Tree Viewer when you need to navigate the failing path in a deeply nested instance.