1 / 6
← PrevNext →

Lesson 1: Your First Schema

Schema Editor
Data Editor
Validation Result

Type in the editors to see validation results.

typepropertiesrequiredadditionalProperties

JSON Schema is a JSON document that describes the shape of another JSON document — it is a contract that your data must satisfy. The "type" keyword specifies what kind of value is allowed: string, number, boolean, array, object, or null. The "required" array lists the property names that must be present in the object; omitting any of them causes a validation error. Finally, setting "additionalProperties" to false locks the schema so that no extra properties beyond those declared in "properties" are permitted.

Why This Matters

Every API, config file, and message queue payload is really just JSON with an implicit shape — JSON Schema makes that shape explicit and machine-checkable. Instead of discovering a missing "email" field when your code throws a TypeError three functions deep, validation catches it at the boundary, with a precise error pointing at the exact field. This is also the foundation for generating API docs, TypeScript types, and mock data from a single source of truth, so the schema you write in this lesson is the same kind of document used to define OpenAPI request bodies, Kafka message contracts, and CLI config files in production systems.

Common Mistakes

  • Assuming "properties" alone restricts the object to those fields.By default JSON Schema allows any extra properties. If you don't also set "additionalProperties": false, a typo like "naem" instead of "name" will pass validation silently as an unrecognized extra field.
  • Listing a field in "required" without defining it in "properties".This is technically valid — the field must be present, but its value is never type-checked. Always define a schema for every property you require.
  • Using "type": "number" for values that should only ever be whole numbers, like an id or a count.Use "type": "integer" instead so that 4.5 correctly fails validation for a field like "age" or "quantity".
  • Forgetting that JSON Schema has no concept of "optional but defaulted".A "default" keyword is only a documentation/tooling hint — it does not get injected into the data during validation, so an omitted optional field stays absent, not defaulted.

Challenge

Add an 'email' field (string, required) to the schema, then add it to the data.

Frequently Asked Questions

JSON Schema describes the expected structure of JSON data — required fields, types, formats, and constraints — so you can validate API requests/responses, config files, and message payloads before they reach application logic, and so tooling can generate docs, types, or forms from the same definition.

For new projects, use Draft 2020-12 (the latest stable draft), referenced with "$schema": "https://json-schema.org/draft/2020-12" as shown in this lesson. Older APIs and tools sometimes still use Draft-07 or Draft-04, which have slightly different keyword names (e.g. "definitions" instead of "$defs").

Yes. JSON Schema validates against JSON's own type system, so the string "5" and the number 5 are different types. A property declared "type": "number" will reject the string "5" — you'd need "type": "string" or ["string", "number"] to accept both.

Yes — omitting "required" (or using an empty array) means every property is optional. This is common for PATCH-style partial update payloads where any subset of fields may be sent.