JSON Schema Validator
Validate JSON payloads against a custom JSON Schema.
JSON Schema Validator
Really checks type, required, properties (recursive), items, enum, const, numeric bounds, string length/pattern, array length/uniqueness, and additionalProperties (draft-07 subset) — a "valid" result never implies more than what was actually checked; any other keyword in your schema is listed separately, not silently ignored.
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The JSON Schema Validator checks a JSON payload against a JSON Schema document and reports whether it conforms — and if it doesn't, exactly which properties failed which constraints. This is the verification counterpart to the JSON Schema Generator: where the generator produces a schema from an example, the validator checks whether new or existing payloads actually satisfy a schema, whether that schema was generated here, hand-written, or pulled from an API specification.
- Validating against a schema catches a category of bug that basic JSON syntax checking cannot: a payload can be perfectly valid JSON — correctly quoted, properly nested, no trailing commas — while still being structurally wrong for what your application expects, such as missing a required field, using a string where a number was expected, or including a value outside an allowed enum. Schema validation checks the payload's shape and constraints, not just its syntax.
- This matters most at integration boundaries: validating an incoming API payload against its documented schema before your application processes it turns a confusing downstream error (a null pointer, a type coercion surprise) into a clear, specific validation message pointing at exactly which field violated exactly which rule.
How It Works
- You provide a JSON Schema document and a JSON payload to check against it.
- The validator walks the payload against the schema's constraints: type checks, required-property checks, string format and pattern checks, numeric range checks, array item and length checks, and enum membership checks, recursing into nested objects and arrays as the schema requires.
- Each constraint violation is recorded with the specific property path where it occurred and a description of which rule was violated.
- The result reports either full conformance, or a list of specific violations — each one naming the exact field and constraint, rather than a single generic failure message.
Usage
- Provide the JSON Schema you want to validate against — from the JSON Schema Generator, a hand-written schema, or an API's published specification.
- Provide the JSON payload you want to check.
- Run the validation.
- Review the result: full conformance, or a specific list of violations naming the exact field and rule each one failed.
- Fix either the payload or the schema depending on which one is actually wrong, and re-validate to confirm.
Examples
- Validating an API request payload and finding a required email field is missing, with the validator naming that exact field rather than a generic 'invalid request' message.
- Validating a configuration file and catching that a value expected to be a number was provided as a string, which basic JSON syntax checking wouldn't have flagged.
- Checking a payload against a schema with an enum-constrained status field and catching a typo'd status value that isn't one of the allowed options.
- Validating a nested object structure and pinpointing that a specific deeply-nested property violates a length constraint, without needing to manually trace through the nesting to find it.
Real-World Use Cases
- Validating an API's incoming request payloads against its documented schema before processing, to reject malformed requests early with a clear error rather than failing confusingly downstream.
- Checking a configuration file against its schema before deploying it, catching a typo'd field name or wrong-type value before it causes a runtime failure.
- Verifying that a third-party API's actual responses match its documented schema, especially after a version upgrade that might have introduced undocumented changes.
- Testing edge-case payloads (missing optional fields, boundary values, unexpected additional properties) against a schema during development to confirm it behaves as intended before relying on it in production.
Best Practices
- Validate at integration boundaries — incoming API requests, configuration loading, third-party responses — rather than only at the very end of a processing pipeline, so a bad payload is caught with a specific error as early as possible.
- Keep your schema and your actual expected payload shape in sync deliberately — when your data format changes, update the schema in the same change, not as an afterthought once validation starts failing unexpectedly.
- Treat a validation failure as informative, not just as a pass/fail gate — the specific field and rule named in the failure is exactly the information needed to fix either the payload or the schema.
- Use additionalProperties: false deliberately when you want to catch unexpected extra fields (useful for strict API contracts), but be aware it will reject payloads with any field beyond what's explicitly listed — make sure that's actually the behavior you want.
Common Mistakes
- Assuming a payload that's valid JSON is automatically 'correct' for your application — syntax validity and schema conformance are separate checks, and only the second one catches structural and type mismatches.
- Setting additionalProperties: false without realizing it will reject a payload that includes any field not explicitly listed in the schema, which is sometimes surprising when an upstream system adds a new field the schema hasn't been updated to allow.
- Not re-validating after either the schema or the expected payload format changes, letting the two silently drift out of sync until a real request fails unexpectedly.
- Reading only the first reported violation and fixing it, then re-running and finding another — when possible, review the full list of violations from one validation pass rather than fixing and re-checking one at a time.
Limitations
- This tool validates a payload's structure and constraints against a schema; it does not validate business logic beyond what the schema itself expresses — a schema can't encode every rule an application might care about (such as a value being valid only in combination with another field's specific value, though JSON Schema's conditional keywords can express some of this).
- Validation is only as good as the schema itself — an incomplete or overly permissive schema will pass payloads a stricter one would correctly reject.
- For generating a starting schema from a sample payload rather than validating against an existing one, use the JSON Schema Generator instead.
Technical Reference Guide
- JSON Schema's validation keywords (type, required, enum, pattern, minimum/maximum, and so on) are defined in the JSON Schema Validation specification, currently at draft 2020-12.
- JSON itself, the data format being validated, is defined independently by RFC 8259 — JSON Schema is a separate, layered specification describing JSON document structure, not part of the JSON grammar itself.
- The additionalProperties keyword, commonly used to enforce strict API contracts, defaults to allowing any additional properties unless explicitly set to false or constrained to a specific schema.
FAQ
Why did my valid JSON fail schema validation?
Being syntactically valid JSON and conforming to a schema are separate checks — a payload can be correctly formatted JSON while still missing a required field, using the wrong type for a value, or including a value outside an allowed enum. Schema validation checks structure and constraints, not just syntax.
What does additionalProperties: false actually do?
It rejects any property in the payload that isn't explicitly listed in the schema's properties. This enforces a strict contract but can cause unexpected rejections if an upstream system adds a new field before the schema is updated to allow it.
How do I know which field caused a validation failure?
The validator reports the specific property path and the exact constraint that was violated for each failure, rather than a single generic error — review the full list, since a payload can violate more than one constraint at once.
Can JSON Schema validate relationships between fields?
To some extent — JSON Schema's conditional keywords (if/then/else, dependentRequired, and similar) can express some cross-field rules, though highly complex business logic may still need separate application-level checks beyond what schema validation alone covers.
Should I validate on every request or just during testing?
Validating incoming payloads at runtime, not just during testing, is what actually protects your application from malformed data reaching code that assumes a specific structure — treat schema validation as a production safeguard, not only a development-time check.
What's the difference between this tool and the JSON Schema Generator?
The Generator produces a schema from a sample payload. This tool does the reverse: checks whether a payload conforms to a schema you already have, whichever way that schema was produced.
Part of this Developer Hub
This utility is part of our comprehensive JSON Workshop topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the API & Web Engineering Lab workshop for complementary engineering workflows.
View all API & Web Engineering Lab tools