JSON Schema Tutorial: Validating Structure and Fields

What JSON Schema actually is

JSON Schema is itself written in JSON, and describes the shape a JSON document must have — which fields are required, what type each field must be, and constraints on values — independent of any particular programming language. A document either conforms to a schema or it doesn't, and a validator library gives you a specific list of violations when it doesn't, rather than a bare pass/fail.

A worked example

{
  "type": "object",
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0 },
    "role": { "type": "string", "enum": ["admin", "editor", "viewer"] }
  },
  "required": ["name", "role"]
}

This schema says: the document must be an object; if name is present it must be a non-empty string; if age is present it must be a non-negative integer; if role is present it must be exactly one of three allowed values; and name/role must both be present regardless (age is optional, since it's not in required).

{ "name": "Ada", "role": "admin" }

✅ Valid — satisfies every constraint, age simply omitted since it's optional.

{ "name": "", "role": "owner" }

❌ Invalid — name violates minLength: 1, and role isn't one of the allowed enum values.

The core keywords worth knowing first

Keyword	Purpose
type	Restricts to a JSON type: string, number, integer, boolean, object, array, null
properties	Defines the schema for each named field in an object
required	Lists which properties must be present
enum	Restricts a value to a fixed set of allowed options
minimum/maximum	Numeric bounds
minLength/maxLength	String length bounds
items	Schema applied to every element of an array

Why "required" doesn't mean "not null"

A common misunderstanding: listing a field in required only says the key must be present — it says nothing about the value itself unless you also constrain its type. A field marked required but typed loosely could still technically satisfy required with a null value, unless type explicitly excludes null. Being precise about both presence (required) and value constraints (type, enum, etc.) together is what actually locks down a field's behavior.

Common mistakes

• Assuming required alone prevents null or wrong-type values. It only checks presence — pair it with an explicit type for the field.
• Forgetting items for array element validation. Without it, a schema restricts that a field is an array but says nothing about what's inside it.
• Writing an overly permissive schema "to be safe." A schema with no required list and loose types validates almost anything, defeating the purpose of having one.

FAQ

Does JSON Schema itself need to be valid JSON?
Yes — a JSON Schema document is itself written in ordinary JSON, using specific reserved keywords that a schema validator library interprets.

What's the difference between required and type?
required lists which keys must exist in the object; type (applied per-property) constrains what kind of value each key must hold — you typically need both together for meaningful validation.

Can JSON Schema validate array contents, not just the array itself?
Yes — the items keyword applies a schema to every element inside the array, letting you validate structure recursively.

Generate a JSON Schema from a real example document with the JSON Schema Generator — runs entirely client-side.