JSON Schema Validator

What this tool does

This tool checks a JSON value against a JSON Schema you paste in, and lists every place the value violates that schema — a missing required field, a value of the wrong type, a number outside its allowed range, a string that doesn't match a pattern, or an array item that fails validation. Every violation found in one pass is reported together with its exact path, so you can fix a batch of problems at once instead of round-tripping through the validator repeatedly.

When you need it

• Checking an API request or response body against its documented schema while debugging an integration, to find exactly which field is wrong instead of guessing from a generic 400 error.
• Validating a config file — application settings, a CI pipeline definition, an infrastructure template — against a schema your team maintains, before deploying it.
• Testing a JSON Schema you're writing, by trying it against both valid and deliberately invalid sample data to confirm it catches what it should.
• Learning how a piece of JSON Schema syntax behaves, by editing the schema or instance and immediately seeing which rule fires.

What subset of JSON Schema is supported

This is a small, pure implementation, not the full JSON Schema specification. It supports type (including arrays of allowed types), required, properties, enum, minimum, maximum, pattern and items. It does not support $ref, oneOf/anyOf/allOf, additionalProperties, format, minLength/maxLength, or draft-specific keywords. This covers the everyday shape of most hand-written schemas — validating an object's required fields, types, numeric ranges, string patterns and array contents — without the complexity of a full spec-compliant validator. If your schema relies on composition keywords or $ref to external definitions, this tool won't evaluate those parts correctly; test with a full-spec validator instead.

Because a "Valid" result that ignored half your schema would be misleading, the result line lists any keyword in your schema that the tool does not evaluate (for example Not checked (unsupported keywords in the schema): additionalProperties, format). Annotation keywords such as title, description and $schema are not flagged. A type name that does not exist ("str" instead of "string") is reported as an error instead of being accepted, and a schema that is not a JSON object is rejected. enum members are compared by value, so an object matches regardless of key order.

How errors are reported

Each error names the exact location of the problem using the same notation you'd use in code: dot notation for object properties (user.age) and bracketed indices for array items (tags[1]). The root of the document, if the failure applies to the whole instance, is labeled (root). Because every applicable check runs rather than stopping at the first failure, a single validation pass can surface a missing required field and a type mismatch elsewhere in the same document together.

A note on required and properties together

The keywords apply based on what the instance is, as in the specification: minimum and maximum check any number, pattern any string, and required and properties any object, even if the schema does not repeat type. required only checks that a key exists on an object — it doesn't validate that key's value. properties is what validates the value at each key, and only runs for keys that are actually present. That means a field can be both missing (a required violation) and, if you supplied a properties schema for it, separately checked for its value once it is present. This mirrors how the JSON Schema specification itself separates presence from correctness.

Limits

Both the schema and the instance are capped at 2 MB of JSON text each. Parsing errors in either one are reported before any schema validation runs, since a schema or instance that doesn't parse as JSON can't be meaningfully checked against anything.