JSON Schema Validator
DataValidate a JSON document against a JSON Schema definition. Supports type, properties, required, items, minimum, maximum, enum, and pattern. Free, client-side.
Reviewed by the thecalcu.com team · Last updated June 28, 2026
What is a JSON Schema?
JSON Schema is a vocabulary for describing the shape and constraints of JSON data. A JSON Schema Validator takes two inputs, a schema document and a JSON data document, and checks whether the data conforms to every rule the schema defines. It is the layer that sits between "is this valid JSON?" and "does this JSON have the structure my application expects?"
This tool implements a subset of JSON Schema Draft-07 entirely in your browser. Paste a schema into the JSON Schema textarea and your data into the JSON Data to Validate textarea. The validator parses both, runs every supported keyword check, and produces a clear Valid or Invalid badge. When validation fails, it reports each error with a dot-notation path, for example, root.user.email: expected type "string", got "number", so you can locate the problem immediately.
All processing is client-side. Your schema and data are never sent to a server, making the tool safe for internal API payloads and configuration files you would prefer to keep private.
For syntax checking without schema constraints, the JSON Validator confirms a string is parseable JSON. For YAML documents, the YAML Validator provides equivalent syntax validation.
Why Use a JSON Schema Validator?
Writing a schema is a contract. A schema says: "every document in this system must look exactly like this." Enforcing that contract without tooling means writing bespoke type-checking code that drifts from the spec over time and misses edge cases. JSON Schema externalises that contract into a declarative document that any standards-compliant validator can check.
Common situations where this tool saves time:
- You are building an API and want to verify that a sample request body satisfies the schema before writing the server-side handler.
- You are integrating with a third-party API and want to confirm that the response you received matches the documented schema.
- You are editing a JSON configuration file for a tool (webpack, ESLint, GitHub Actions) that ships a JSON Schema and want to know whether your edits are valid before running the tool.
- You are debugging a production error and want to replay the failing payload against the schema to identify which field caused the rejection.
- You are documenting an API and want to verify that every example in the documentation actually passes schema validation.
The error paths in the output use dot notation, root.address.postcode rather than a raw JSON Pointer, so errors are readable without understanding the JSON Pointer specification.
Who Should Use This Validator?
Backend developers designing or consuming REST and GraphQL APIs. JSON Schema is the foundation of OpenAPI request/response validation, checking a payload against the relevant schema fragment is the fastest way to reproduce a 400 Bad Request without spinning up the full application.
Frontend developers validating form submission payloads before they reach the API. If the API publishes a schema for its endpoints, this tool lets you test sample payloads directly.
DevOps and platform engineers working with JSON-format infrastructure configuration (AWS CloudFormation, Terraform variable files, Kubernetes CRDs exported as JSON). Many of these tools publish JSON Schemas; validating configs against them before deployment catches structural errors before they cause a pipeline failure.
API integration engineers receiving webhooks or third-party data feeds. Pasting an incoming payload against the documented schema confirms the external system is sending data in the expected shape, and when it is not, the error paths identify exactly which fields deviate.
QA and test engineers building regression test suites. Storing the schema alongside expected-response fixtures and validating them here confirms that fixture files stay in sync with the schema as both evolve.
For full OpenAPI spec validation, checking the spec document itself, not individual request bodies, use the OpenAPI Validator.
What Insights Does the JSON Schema Validator Give You?
When validation passes, the tool shows a green Valid badge and confirms that all type, required-field, and constraint checks passed. This means every property listed in required was present, every type assertion matched the actual value type, and every constraint keyword (minimum, maxLength, pattern, and so on) was satisfied.
When validation fails, the tool shows a red Invalid badge, a summary count of errors found, and a list of individual errors, up to 20, to avoid overwhelming the output for severely malformed data. Each error includes:
- The dot-notation path to the failing value (e.g.
root.user.age) - What was expected (e.g.
expected type "number") - What was found (e.g.
got "string") - For constraint failures, the specific constraint and the actual value (e.g.
14 < minimum 18)
The validator also catches schema-level issues separately: if the Schema textarea contains invalid JSON, it reports "Schema is not valid JSON" before attempting any validation. If the Data textarea contains invalid JSON, it reports "JSON data is not valid JSON." This distinction matters because a schema parse failure and a validation failure are two different problems requiring different fixes.
How to use this JSON Schema calculator
- Paste your JSON Schema into the JSON Schema textarea. The default example shows a schema that requires an object with
name(string, non-empty) andage(number, 0–120) properties. Replace it with your own schema. - Paste the JSON document you want to validate into the JSON Data to Validate textarea. The default example shows
{ "name": "Alice", "age": 30 }, which passes the default schema. - The validator runs automatically as you type. Check the Valid / Invalid badge at the top of the results section.
- If the badge shows Invalid, read the error list. Each entry shows the path (e.g.
root.name) and the specific rule that failed (e.g.string length 0 < minLength 1). Navigate to that field in your data and apply the fix. - If the badge shows "Schema is not valid JSON" or "JSON data is not valid JSON", use the JSON Validator to fix the syntax of the offending input first, then return here.
- Iterate until the Valid badge appears and every required constraint is satisfied.
Tip: if you are testing a schema you are writing rather than data you received, try submitting data that should fail to confirm the schema rejects it correctly, this catches overly permissive schemas before they reach production.
Show formula & methodology ↓Show less ↑
Formula & Methodology
This validator implements a recursive descent algorithm over the JSON Schema keyword set from Draft-07. Given a schema object and a data value, it evaluates every applicable keyword and collects all errors, rather than stopping at the first failure. Error paths are accumulated by passing the current path string (root,root.propertyName,root.arrayName[index]) down through recursive calls. ### Supported keywords by category Type and value identity -type, accepts a string or array of strings;"integer"is treated as a subtype of"number"and additionally requiresNumber.isInteger(value)to be true -enum, value must deep-equal one of the listed items (compared viaJSON.stringify) -const, value must deep-equal the specified constant String constraints -minLength,maxLength, checked againststring.length(character count) -pattern, tested withnew RegExp(pattern).test(value)Number constraints -minimum,maximum, inclusive bounds -exclusiveMinimum,exclusiveMaximum, exclusive bounds (Draft-07 number form) -multipleOf, checked viaNumber.isInteger(value / multipleOf)Array constraints -items, if an object schema, applied to every element; if an array of schemas, applied positionally -minItems,maxItems, checked againstarray.length-uniqueItems, all elements compared viaJSON.stringify; first duplicate reported with its index -contains, at least one array element must match the sub-schema Object constraints -required, each listed key must be present in the object -properties, each defined property is validated recursively against its sub-schema if present -additionalProperties, iffalse, any key not inpropertiesis rejected; if an object schema, applied to all keys not inproperties-patternProperties, each key matching the pattern regexp is validated against the associated sub-schema -minProperties,maxProperties, checked againstObject.keys(object).lengthLogical combinators -allOf, data must pass every sub-schema in the array -anyOf, data must pass at least one sub-schema -oneOf, data must pass exactly one sub-schema -not, data must fail the sub-schema ### Working example Schema, requires an object with ausername(string, 3–20 characters) and arole(one of"admin","editor","viewer"):json { "type": "object", "required": ["username", "role"], "properties": { "username": { "type": "string", "minLength": 3, "maxLength": 20 }, "role": { "type": "string", "enum": ["admin", "editor", "viewer"] } }, "additionalProperties": false }Data that fails,usernameis too short androleis not in the enum:json { "username": "ab", "role": "superuser" }Errors produced:root.username: string length 2 < minLength 3 root.role: value must be one of "admin", "editor", "viewer"### Scope and limitations This tool does not support: -$ref, schema references are not resolved; the keyword is silently ignored -$defs/definitions, referenced sub-schemas via$refare not inlined -format, the keyword is accepted but not validated -if/then/else, conditional application keywords from Draft-07 are not implemented - Schema vocabularies,$schemadeclaration enforcement, or annotation collection For production-grade validation with full Draft-07 support including$refresolution, use Ajv in your codebase.
Frequently Asked Questions