JSON Schema Validator — Validate JSON Against Draft 2020-12

JSON Schema Validator At a Glance

A JSON Schema validator checks a JSON value against an explicit set of structural and content rules. A schema can require an object to contain particular properties, restrict fields to strings or numbers, define allowed values, and apply constraints such as minimum length or numeric ranges. This tool accepts a schema and a separate data document, validates them using JSON Schema draft 2020-12, and reports failures with property paths and the rule responsible for the problem.

The validator checks the supplied data; it does not redesign the schema, contact an API, or verify that the contents are truthful. A valid address string can still point to the wrong place, and a correctly typed account identifier may belong to someone else. Treat a successful result as a useful contract check, not as evidence that the underlying record is trustworthy or appropriate for publication.

How to Validate JSON Against a Schema

Paste your JSON Schema into the first editor and the value being tested into the second. Both editors require valid JSON syntax. Run the validator and inspect the results. For a passing document, the page reports that no schema violations were found. If validation fails, the report lists paths such as /customer/email, the name of the violated constraint, and a message describing what the schema expected. You can download the structured report for troubleshooting or a test record.

Use a complete schema when possible, especially if your application depends on nested objects or arrays. For example, it is not enough to require an orders property of type array when each order must also have an orderId and a total. Describe the array's items using a nested schema, then test a document with a missing orderId to confirm that the validator reports the expected failure. The JSON Formatter and Validator is useful for correcting broken JSON syntax before checking any schema rules.

JSON Schema Draft 2020-12 and Supported Rules

JSON Schema has evolved through several published drafts, and keyword behavior is not identical across all of them. This tool is configured for draft 2020-12. Common checks include type, properties, required, additionalProperties, enum, const, minLength, maxLength, minimum, maximum, pattern, items, and combinators such as allOf, anyOf, and oneOf. The underlying validator also handles many more draft-defined features, including supported standard string formats when the format extension is loaded.

A schema written for an older draft can look similar while differing in important array or reference semantics. If its $schema identifier explicitly names a different draft, this implementation rejects it instead of quietly interpreting the document under different rules. Convert the schema deliberately or use an environment that supports the intended draft. When a team maintains API contracts, recording the supported draft alongside the schema avoids unexpected disagreements between tools.

Required Properties and Missing Values

The required keyword lists properties that an object must contain. A property can exist with a null value and still satisfy required, unless another rule disallows null. For example, a schema requiring email does not necessarily reject {"email":null} until email also has a string type. Similarly, an empty string is not the same as a missing property; it can pass a string type check while failing a minLength constraint. Understanding these distinctions prevents schemas from appearing stricter than they really are.

Consider a registration record that needs a username, contact email, and consent flag. Make each property required if it must be present, then state the appropriate types. When blank strings should be rejected, set a minimum string length or a format and content rule that matches the application's actual needs. A validator can enforce these declared properties, but it cannot decide whether the person entering the record understood a privacy policy or gave valid consent.

Numbers, Strings, and Identifier Fields

JSON distinguishes numeric values from strings, and schema validation respects that difference. A price expressed as 19.99 is a number; "19.99" is a string, even if humans read them similarly. A zip code, invoice identifier, SKU, or account number is often better represented as a string because leading zeros and punctuation may be meaningful. A schema that automatically converts these values to numbers can discard information before validation even begins.

For decimal currency, floating-point representation can introduce precision questions. JSON Schema minimum or maximum can check numeric bounds, but financial calculations may still need decimal arithmetic elsewhere. The validator does not transform values or round amounts. If a document fails because a price came from a CSV export as a string, investigate the source conversion process rather than automatically changing the schema to accept any type.

Nested Objects and Arrays of Records

Many JSON documents contain nested contact information, product variants, or groups of events. A schema can describe the nested structure directly: an order object may require shippingAddress, and shippingAddress may require city and country. If an individual field fails, the error path points into that nested object. An array schema can likewise check each element's type or structure, which helps catch a single malformed entry within an otherwise acceptable list.

The difference between an object and an array matters even when they look similar in formatted text. An object with keys "0" and "1" is not an array containing two values. When comparing data across versions, the JSON Diff Tool identifies which properties or positions changed, while a schema validator explains whether the revised structure violates the expected contract. These questions complement each other; neither substitutes for the other.

Understanding Validation Error Paths

An error report typically includes an instance path pointing to the submitted data, a keyword identifying the rule, and a schema path indicating where the rule came from. For a required property, the instance path may point to the parent object rather than to a property that is missing entirely. That is not a bug: there is no value at the absent property's path to evaluate. The keyword and message provide the remaining context needed to identify the missing name.

When many failures appear, correct the earliest structural problems first. If the submitted value has the wrong overall type, several nested constraints may become irrelevant or confusing until the structure is repaired. A path is a diagnostic locator, not a link to edit the document automatically. This tool leaves the supplied JSON unchanged so the person reviewing errors can decide how to correct it without accidentally discarding values.

Schema References and Remote Resources

Schemas can refer to other definitions using $ref. References inside the supplied schema can be useful for declaring a reusable address or product shape once and applying it in several places. Remote references are a different matter: resolving a URL may require access to a separate schema file whose contents and version can change. This implementation does not fetch remote schemas from arbitrary URLs, so unresolved external references result in a compilation error rather than a misleading validation success.

For repeatable checks, keep the needed definitions together or manage them explicitly in a trusted validation environment. Avoid allowing an untrusted document to tell a production service where to download code or policy definitions. Although this page checks JSON Schema data rather than executing the submitted values, schema complexity and references can still affect processing cost. Input size limits and a report cap help keep the tool useful for ordinary checks rather than unbounded validation workloads.

A Practical API Contract Example

Suppose an API expects a product object with a string sku, a nonnegative number price, and an array tags whose entries are strings. A data record with sku 00123 expressed as a number may fail the string constraint, and a price of -5 should fail the nonnegative requirement. A tags value containing an object instead of a string will generate an error at the relevant array position. This turns an informal expectation into rules that can be checked consistently across several test responses.

A passing example still needs integration testing. The schema does not know whether the SKU exists in inventory, whether prices include tax, or whether an API key has permission to update the product. Those conditions may require database lookups or service-specific checks. Use schema validation before submitting data to an application, not as the sole assurance that downstream processing will succeed.

Schema Validation and Data Quality

A document can match a schema while containing duplicate records, unreasonable values within broad limits, or business rules that were never expressed in the schema. Validation is strongest when the rules reflect real data requirements instead of accepting any object that parses successfully. If every field uses an unrestricted string type, passing validation offers little assurance beyond syntax. Make constraints specific where the contract has a clear reason for them, and keep optional fields optional when they really are not required.

When the same information passes through spreadsheets and JSON APIs, watch for changes in nulls, empty cells, and inferred numbers. The JSON to CSV converter turns structured values into tabular rows, but nested data may need flattening choices that alter its original shape. Validate the data at the point where its intended JSON structure is available, and rerun the check after significant transformations or schema updates.

Frequently Asked Questions About JSON Schema Validation