JSON Schema Is Everywhere, Debugging It Rarely Is Easy
JSON Schema shows up in API contract validation, config file linting, form generation, and OpenAPI specs — but the error output from many validators is either a stack trace or a single generic "validation failed" message that tells you nothing about which field broke or why.
What a Useful Validation Error Actually Needs
A useful error has three parts: the exact path to the offending field (not just "somewhere in the object"), which rule it violated, and enough context to see the actual vs. expected value. "age: expected number, got string" is useful. "Validation error at line 1" is not.
The Keywords That Cover Most Real Schemas
You don't need every obscure JSON Schema keyword to validate the vast majority of real-world payloads. The core set that shows up constantly is:
type— including the integer-vs-number distinction, since JSON itself doesn't distinguish themrequiredandproperties— the backbone of object validationitems— validating every element of an array against a sub-schemaminimum/maximum— numeric boundsminLength/maxLength— string length boundspattern— regex-constrained strings like emails or IDsenum— a fixed set of allowed valuesadditionalProperties: false— catching typos and unexpected fields
A Common Trap: Type Coercion Hiding Bugs
A payload with "age": "30" instead of "age": 30 looks harmless in a lot of loosely-typed code paths — string concatenation and comparisons often "just work" until they don't. A schema with type: "number" on that field catches it immediately, before it becomes a production bug three services downstream.
Nested Errors Need Nested Paths
Once you're validating objects with nested objects and arrays, a flat error list stops being useful unless each error carries its full path — $.user.address.zip, not just zip. Any validator that flattens nested structures without path tracking will leave you searching the payload manually.
Validating Without Installing a Library
For a quick check — confirming an API response matches its documented schema, or sanity-checking a config file before committing it — pulling in a full validation library is often overkill. The JSON Schema Validator runs the same core logic entirely in your browser: paste a schema and a payload, click Validate, and get a pass/fail result with every specific error listed by path.
- Paste your JSON Schema.
- Paste the JSON payload to check.
- Click Validate and read the field-by-field error list.
Nothing you paste is uploaded anywhere — the validation runs locally in your browser.
Frequently Asked Questions
type (including integer vs number), required, properties, items, minimum, maximum, minLength, maxLength, pattern, enum, and additionalProperties — the core keyword set used by the vast majority of real-world schemas, applied recursively through nested objects and arrays.
A specific list of every violation, each with the exact field path and the rule it broke — for example "$.age: expected type number, got string" or "$.email: missing required property" — instead of a single generic failure message.
Yes — the JSON Schema Validator does exactly this, with real per-field error reporting, entirely in your browser. It's a one-time $6.99 purchase — no subscription, no account required.
It supports the common keyword set shared across draft-07 and 2020-12 (type, required, properties, items, bounds, pattern, enum, additionalProperties). It focuses on the keywords used in practice rather than every draft-specific edge case.
Yes — the items keyword is applied to every element of an array, including arrays of nested objects, and any errors found inside array elements report their full indexed path, e.g. $.users[2].email.