Validate JSON data against a JSON Schema (Draft 7) with detailed error reporting. Free browser-based tool with example buttons and path-level diagnostics.
Paste your JSON data into the left editor panel.
Paste a JSON Schema into the right panel, or load one of the example buttons to populate both panels instantly.
Click Validate to check the data against the schema.
Review any validation errors — each shows the path, the violated keyword, and a clear message.
Validates type, required, properties, items, enum, pattern, min/max, allOf/anyOf/oneOf, $ref, and more.
Each error identifies the exact JSON path where the violation occurred, making it easy to fix issues.
One-click examples for API responses, package.json, and config files populate both the data and schema panels instantly.
All validation runs locally in your browser — your data and schemas are never sent to any server.
JSON schemas often validate production API payloads, configuration files with credentials, and healthcare or financial data. Because this validator runs entirely in your browser, neither your data nor your schema is ever transmitted to an external server. There is zero risk of data exposure, making it safe for HIPAA-sensitive, PCI-regulated, or confidential enterprise data.
When validation fails, every error includes the exact JSON Pointer path (e.g., $.users[0].email), the violated keyword (e.g., format), and a human-readable message. This precision eliminates guesswork — you know exactly where the problem is and what rule was broken, even in deeply nested structures with hundreds of fields.
The validator supports all core JSON Schema Draft 7 keywords including type, required, properties, additionalProperties, items, enum, const, pattern, format, minimum, maximum, minLength, maxLength, allOf, anyOf, oneOf, not, and local $ref resolution. This coverage handles real-world schemas used in production API contracts.
Start validating immediately — no account creation, no email verification, no daily caps. Validate a single object or run hundreds of checks per session with no restrictions. Example buttons are included so you can explore the tool's capabilities without writing a schema from scratch.
JSON Schema is a powerful vocabulary for annotating and validating JSON documents. It defines the expected structure, data types, constraints, and relationships within a JSON payload. Originally designed to describe API contracts, JSON Schema is now used across configuration management, form generation, documentation, and data quality enforcement.
A JSON Schema is itself a JSON document that describes the expected shape of another JSON document. It specifies which properties should exist, what types they should have, what values are acceptable, and how nested structures should be organized. The schema acts as a contract — any JSON document that conforms to the schema is considered valid.
JSON Schema Draft 7 defines several categories of validation keywords:
type keyword restricts values to specific types (string, number, integer, boolean, null, array, object). Union types are supported: "type": ["string", "null"] allows either.minLength, maxLength, pattern (regex), and format (email, date, uri, uuid, ipv4, ipv6) validate string content.minimum, maximum, exclusiveMinimum, exclusiveMaximum, and multipleOf enforce numeric ranges.required lists mandatory properties. properties defines per-property schemas. additionalProperties controls whether unlisted keys are allowed.items validates each element. minItems, maxItems, and uniqueItems enforce collection rules.allOf (must match all), anyOf (must match at least one), oneOf (must match exactly one), and not (must not match) combine sub-schemas for complex validation.$ref with JSON Pointer syntax enables schema reuse by referencing definitions elsewhere in the document.Always set additionalProperties: false when you want strict validation — otherwise, unlisted keys pass silently. Use $ref to define reusable sub-schemas in a definitions block, keeping schemas DRY and maintainable. Include description fields in your schema for self-documenting contracts. Test schemas against both valid and invalid data to ensure constraints work as intended.
JSON Schema has evolved through several drafts, each adding capabilities. Draft 4 introduced the core vocabulary that most developers learned first. Draft 6 added const (exact value match), contains (at least one array item matches), and propertyNames (validate key names). Draft 7 added if/then/else conditional validation, readOnly/writeOnly annotations, and contentMediaType for describing encoded string content. The latest drafts (2019-09 and 2020-12) introduced vocabularies, dynamic references, and unevaluatedProperties for stricter composition. Draft 7 remains the most widely deployed version and is recommended for most production use cases due to its excellent tooling support across all major programming languages.
Several validation patterns appear repeatedly in real-world schemas. Nullable fields use "type": ["string", "null"] to allow either a value or null. Discriminated unions use oneOf combined with a constant type field to validate polymorphic objects — for example, a payment object that can be either a credit card or bank transfer, each with different required fields. Dependent required fields use the dependencies keyword to require certain fields only when other fields are present, such as requiring a billing address only when a payment method is provided. Enumerated constants use enum arrays to restrict values to a predefined set, commonly used for status fields, country codes, and configuration options. Mastering these patterns enables you to express complex business rules declaratively rather than writing custom validation logic in application code.
Most schema failures fall into a handful of recurring categories. A type mismatch happens when a value looks right to a human but has the wrong JSON type, such as "42" instead of 42 or "true" instead of true. A required field missing error means the payload omitted a property listed in the schema's required array. An enum violation occurs when a field contains a value outside the approved set, such as "archived" when only "draft" and "published" are allowed.
More advanced failures often come from composition and strictness settings. additionalProperties: false rejects any unexpected field, which is excellent for contract enforcement but frequently surfaces hidden producer changes. anyOf and oneOf conflicts are another common source of confusion: anyOf requires matching at least one branch, whereas oneOf requires matching exactly one branch. If the payload matches zero branches or multiple branches, validation fails. Finally, unresolved $ref errors usually point to a typo in the JSON Pointer path or to a missing definition block. When reading validator output, fix top-level structural errors first; many downstream path errors disappear once the parent object conforms to the intended schema.
| Error type | Typical cause | Practical fix |
|---|---|---|
| Type mismatch | String sent instead of number/boolean | Coerce input before validation or update the schema if both types are acceptable |
| Required missing | Producer omitted a mandatory field | Add the field or remove it from required if it is genuinely optional |
| Enum violation | Unexpected status/code value | Normalize upstream values or extend the schema's enum intentionally |
oneOf conflict | Payload matches more than one branch | Add a discriminator field or tighten each branch |
Unresolved $ref | Broken pointer or missing definition | Verify the pointer path and keep reusable definitions centralized |
JSON Schema is a standard vocabulary (currently at Draft 7 / Draft 2020-12) that defines the expected structure, types, and constraints of a JSON document. It is itself written in JSON and acts as a contract — any JSON document that conforms to the schema is considered valid. JSON Schema is used for API validation, configuration checking, form generation, and documentation.
Yes. All validation processing happens locally in your browser using JavaScript. Neither your JSON data nor your schema is transmitted to any server, logged, or stored. This makes the tool safe for validating sensitive payloads including API tokens, medical data, financial records, and internal configuration files.
The tool supports JSON Schema Draft 7 core validation keywords including type, required, properties, additionalProperties, items, enum, const, pattern, format, minimum, maximum, exclusiveMinimum, exclusiveMaximum, minLength, maxLength, minItems, maxItems, uniqueItems, minProperties, maxProperties, allOf, anyOf, oneOf, not, and local $ref resolution.
Each error shows three pieces of information: the path (e.g., $.users[0].email) identifying exactly where in your JSON the problem is, the keyword (e.g., format, required, type) identifying which schema rule was violated, and a human-readable message explaining the issue. Fix the errors from top to bottom.
The example buttons load pre-built schema and data pairs for common use cases: an API response schema, a package.json schema, and a config file schema. They populate both panels in one click so you can explore the validator without writing a schema from scratch.
Yes. The validator recursively checks nested objects and arrays at every depth level. If a nested property violates its schema, the error path shows the full path (e.g., $.config.database.port) so you can locate the issue precisely.
When additionalProperties is set to false in a schema, any property in the JSON data that is not listed in the properties object will cause a validation error. This is useful for strict API contracts where unexpected fields should be rejected rather than silently accepted.
Yes. The tool supports local $ref references using JSON Pointer syntax. Define reusable sub-schemas in a definitions block and reference them with $ref: '#/definitions/address'. This keeps schemas DRY and is the standard approach for complex, production-grade schemas.
The format keyword supports: email, date (YYYY-MM-DD), date-time (ISO 8601), uri, ipv4, ipv6, and uuid. Unknown formats are silently accepted per the JSON Schema specification, which treats format validation as optional by default.
Yes. There are no file size or complexity limits. Validation runs entirely in your browser, so the practical limit depends on your device's memory. Most modern devices handle documents with thousands of properties across deep nesting levels without issues.
Draft 7 is the most widely deployed version and has excellent tooling support across languages. Draft 2020-12 adds newer vocabulary features such as unevaluatedProperties, dynamic references, and a clearer modular specification model. For many production APIs, Draft 7 remains the compatibility-friendly default unless you specifically need newer composition features.
Yes. Nested objects and arrays are first-class use cases for JSON Schema. You define child schemas inside properties and items, and the validator recursively applies them at every level, reporting the full failing path when something breaks.
It makes object validation strict by rejecting any property not explicitly listed in the schema's properties block. This is useful for API contracts where unexpected keys should fail fast instead of being silently ignored, but it also means producers must update the schema whenever they introduce new fields.
Compare JSONPath libraries in JavaScript, Python, and Java, including syntax differences, return modes, filters, and portability pitfalls.
Read more →Explore practical JSON Schema examples for user registration APIs, product catalogs, app configs, and CI/CD pipelines with reusable patterns.
Read more →Learn JSON Schema Draft 7 validation including types, required fields, patterns, and composition keywords. With practical examples for API contracts.
Read more →Practical JSON API best practices: response envelopes, naming conventions, error formats, pagination, versioning, security, and performance for REST APIs.
Read more →Complete guide to JSON syntax, data types, common parsing errors, and how JSON compares to YAML, XML, and other formats. With code examples.
Read more →