JSON Schema Examples: Required, Enum, Arrays, and Objects

Q: What does a minimal JSON Schema look like?

The simplest valid JSON Schema is just an empty object: {}. An empty schema validates any JSON value. A minimal useful schema specifies a type: {"type": "string"} accepts any string, {"type": "object"} accepts any object. To be more specific, add "properties" and "required": {"type": "object", "required": ["id"], "properties": {"id": {"type": "integer"}}}. This is the minimal schema that actually constrains something useful — it requires an object with an integer "id" field. Always include "$schema" in schemas you share, for example "$schema": "http://json-schema.org/draft-07/schema#", so validators know which specification to apply.

Q: How do I write a JSON Schema for a user object?

A typical user object schema includes required fields like "id" and "email", optional fields like "name", and type constraints on each: {"$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": ["id", "email"], "properties": {"id": {"type": "integer", "minimum": 1}, "email": {"type": "string", "format": "email"}, "name": {"type": "string", "maxLength": 100}, "role": {"type": "string", "enum": ["admin", "user", "guest"]}}}. The "format": "email" hint validates email structure in validators that enforce formats. Add "additionalProperties": false if you want to reject objects with unexpected fields — useful for strict API contracts.

Q: How do I validate a list of items with JSON Schema?

Use the "array" type with the "items" keyword to constrain all elements: {"type": "array", "items": {"type": "object", "required": ["sku", "qty"], "properties": {"sku": {"type": "string"}, "qty": {"type": "integer", "minimum": 1}}}}. Every element must match the "items" schema. You can also add "minItems": 1 to require at least one item, "maxItems": 100 to cap the list size, and "uniqueItems": true to disallow duplicates. In draft 2020-12, the "prefixItems" keyword replaces "items" for positional (tuple) schemas, while "items" in that draft applies to additional elements beyond the defined positions.

Q: What is the difference between items and prefixItems in JSON Schema?

In draft-07 and earlier, "items" serves two roles: when set to a single schema, it validates all array elements; when set to an array of schemas, it validates elements at specific positions (tuple validation). In draft 2020-12, these roles are separated: "prefixItems" (an array of schemas) validates elements at specific positions, and "items" (a single schema) validates any additional elements beyond the prefix. For example, in draft 2020-12: {"prefixItems": [{"type": "string"}, {"type": "integer"}], "items": false} means the array must have exactly two elements — a string then an integer — and no more. This separation makes intent clearer and avoids ambiguity.

Q: How do I allow additional properties in JSON Schema?

By default, JSON Schema allows additional properties — any key not listed in "properties" is permitted. To explicitly allow additional properties of a specific type, use "additionalProperties" with a schema: {"type": "object", "properties": {"name": {"type": "string"}}, "additionalProperties": {"type": "string"}}. This allows any extra keys as long as their values are strings. To allow any additional properties (the default behavior), omit "additionalProperties" or set it to true. To reject all additional properties, set "additionalProperties": false — any key not listed in "properties" or "patternProperties" will cause validation to fail.

Q: How do I use $ref to reuse schema definitions?

Define reusable schemas in the "$defs" section (called "definitions" in draft-07) and reference them with "$ref" using a JSON Pointer. For example: {"$defs": {"Address": {"type": "object", "required": ["city"], "properties": {"street": {"type": "string"}, "city": {"type": "string"}}}}, "type": "object", "properties": {"billing": {"$ref": "#/$defs/Address"}, "shipping": {"$ref": "#/$defs/Address"}}}. This defines "Address" once and reuses it for both "billing" and "shipping" properties. "$ref" can also point to external schema files using a URL. Using "$ref" keeps large schemas maintainable and avoids copy-paste errors.

Last updated: May 12, 2026

These 12 JSON Schema patterns are copy-paste ready and tested against Ajv 8 (100M+ weekly npm downloads, the most widely used JSON Schema validator). Each example ships with the schema, 1 valid input, and 1 invalid input that shows exactly what the validator rejects — validation runs in under 1ms for typical objects. Patterns covered: required fields, 3 string format validators (email, uri, date-time), enum constraints, number ranges with minimum/maximum, array length limits and item type rules, nested objects with additionalProperties: false, nullable fields, conditional validation with if/then, and schema composition with oneOf and anyOf.

Object with required fields

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "format": "email" },
    "name": { "type": "string" }
  }
}

Enum example

{
  "type": "string",
  "enum": ["pending", "active", "disabled"]
}

Array of objects

{
  "type": "array",
  "items": {
    "type": "object",
    "required": ["sku", "qty"],
    "properties": {
      "sku": { "type": "string" },
      "qty": { "type": "integer", "minimum": 1 }
    }
  }
}

For a broader walkthrough of these keywords, see JSON Schema tutorial.

String pattern example

{
  "type": "string",
  "pattern": "^[A-Z]{3}-\d{4}$"
}

Disallow extra fields

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string" }
  }
}

Nullable field example

{
  "type": "object",
  "properties": {
    "deletedAt": {
      "type": ["string", "null"],
      "format": "date-time"
    }
  }
}

Test schema examples against real JSON

Paste these snippets into Jsonic's JSON Schema Validator to validate real payloads in the browser.

Open JSON Schema Validator

Frequently asked questions

What does a minimal JSON Schema look like?

The simplest valid schema is {} which accepts any JSON value. A minimal useful schema specifies a type: {"type": "object"}. Add properties and required to actually constrain structure.

How do I write a JSON Schema for a user object?

Combine type, required, properties, and format hints: require id (integer) and email (string with format "email"), make name optional, and use enum for a role field. Add additionalProperties: false for strict API contracts.

How do I validate a list of items with JSON Schema?

Use {"type": "array"} with items set to an object schema. Add minItems to require at least one item, maxItems to cap the list, and uniqueItems: true to prevent duplicates.

What is the difference between items and prefixItems in JSON Schema?

In draft-07, items as an array validates elements at specific positions (tuple). In draft 2020-12, prefixItems handles positional schemas and items applies only to additional elements beyond the defined prefix.

How do I allow additional properties in JSON Schema?

By default, JSON Schema allows additional properties. Set additionalProperties: false to reject unknown keys. Set it to a schema object like {"type": "string"} to allow extra keys only if their values match that schema.

How do I use $ref to reuse schema definitions?

Define reusable schemas in the $defs section and reference them with {"$ref": "#/$defs/SchemaName"}. This lets you define a sub-schema once (such as an Address) and reuse it across multiple properties without duplication.