What is JSON Schema and why do I need it?
JSON Schema is a vocabulary for describing the shape of JSON data - required keys, allowed types, value ranges, string patterns, and enums. It lets you validate input from clients before processing, document the expected shape of an API, and generate forms or types automatically. A schema turns informal expectations into machine-checkable contracts that catch bugs at the boundary instead of deep in business logic.
Which JSON Schema draft does the validator support?
Most modern validators support drafts 4, 6, 7, 2019-09, and 2020-12, though specific keyword behavior differs between drafts. The draft is declared in the schema with a $schema property pointing to the meta-schema URL. If you omit it, the validator picks a default - usually 2020-12 - which may behave differently from older tooling. Always set $schema explicitly for portability.
What is the difference between required and the type keyword?
Required is an array of property names that must be present on an object - a missing key fails validation. Type restricts the allowed JSON type (string, number, boolean, array, object, null) but does not say anything about presence. A property can be required and have a flexible type, or be optional but strictly typed when present. The two keywords work together rather than overlapping.
How do I validate string formats like email or date?
Use the format keyword with values like email, date, date-time, uri, uuid, or ipv4. Format checking is technically optional in the spec - some validators only treat it as an annotation unless you turn on strict-format mode. Rely on it for documentation, but if you need hard guarantees, combine format with a pattern keyword that pins down the exact regex.
Can a schema reference another schema?
Yes. Use the $ref keyword with a JSON Pointer or URI to reuse definitions, either inside the same document via a definitions or $defs section, or across files using a base URL. This keeps schemas DRY and lets you share common types like address or money across many endpoints. The validator resolves references during validation, so nothing extra is required.
Why does my data fail validation when it looks correct?
The most common causes are extra properties when additionalProperties is set to false, type mismatches like a string where a number is expected, missing required keys, and pattern mismatches that fail silently. The validator produces a list of error paths showing exactly which value failed which rule - read these paths carefully because they pinpoint the bad spot in the data.
