JSON Schema Validator Online

What JSON Schema Actually Checks

A JSON parser tells you whether a document is syntactically valid JSON. That is a low bar: a missing comma fails, and absolutely everything else passes. JSON Schema is the layer above, describing what a valid document means for your application rather than for the parser.

A schema is itself a JSON document, which is the design decision that makes the whole thing practical. Schemas can be stored, versioned, diffed, transmitted over an API, and validated by other schemas, all with tooling you already have. There is no separate grammar to learn, only a vocabulary of keywords.

The keywords are assertions about a value. Applied to an instance they produce a pass or a fail, and on failure a validator reports which part of the document broke which rule, expressed as a JSON Pointer path.

Draft Versions

Draft-07 remains the version with the broadest library support across languages, and it is the safe default unless you specifically need something newer. The most visible difference for anyone moving forward is tuple validation: draft-07 uses an array value for items, while 2020-12 uses prefixItems and reserves items for the rest of the array. Declare your draft in the $schema keyword so validators know which rules to apply rather than guessing.

Core Keywords

One trap worth naming: required and properties are independent. Listing a key under properties does not make it mandatory, and a key can be listed in required without appearing in properties at all. Forgetting required is the single most common reason a schema passes documents it should reject.

A Worked Example

Three separate failures, each with a pointer to the offending location and the keyword that rejected it. A validator reports all of them at once rather than stopping at the first, which is what makes schema errors usable as form validation messages.

Where Schemas Get Used

• API request validation. Reject a malformed body at the edge with a precise error instead of letting it reach business logic and fail obscurely.
• Configuration validation. Catch a typo in a config file at startup with a clear message rather than at three in the morning when a feature silently misbehaves.
• OpenAPI specifications. The components section of an OpenAPI document is JSON Schema, so learning one teaches you most of the other.
• Form generation. Libraries render a working form directly from a schema, so the validation rules and the UI cannot drift apart.
• Editor autocomplete. Add a $schema key to a config file and editors offer completion, inline documentation, and red squiggles while you type.
• Test fixtures and contract testing. Assert that a recorded response still matches the agreed shape after a dependency changes.
• Documentation. A schema with description and examples keywords is machine readable documentation that cannot go stale.

Schemas Versus TypeScript Types

They look like they do the same job and they operate at opposite ends of the program lifecycle.

A type asserts that a value has a shape. A schema checks it. Casting a fetch response with as tells the compiler to stop asking questions and does absolutely nothing to the bytes that arrived. If the API changed last night, your typed code walks straight into undefined.

The two are complements rather than competitors. Use types everywhere inside your own code, where you control both sides, and validate with a schema at every trust boundary: HTTP requests, webhook payloads, uploaded files, message queue events, and configuration read from disk. Tools exist to generate types from a schema so the two never disagree, which gives you one source of truth and both kinds of checking.