Free JSON Schema Validator

JSON Schema is the standard way to describe the structure of JSON data. It lets you define what properties an object should have, what types those properties should be, which ones are required, and what constraints to enforce — then validate actual data against those rules. Our validator runs the industry-standard Ajv library directly in your browser, supporting all modern JSON Schema drafts from Draft 4 through Draft 2020-12.

What Is JSON Schema and Why Validate Against It?

JSON Schema is a declarative vocabulary for annotating and validating JSON documents. Think of it as a contract or blueprint for your data. Where a TypeScript interface describes the shape of a JavaScript object at compile time, JSON Schema describes and validates the shape of JSON data at runtime — and across any programming language.

A JSON Schema is itself a JSON document that describes the type of each property (string, number, boolean, object, array, null), required vs. optional properties, string formats (email, URI, date-time, UUID), numeric ranges (minimum, maximum), string constraints (minLength, maxLength, pattern), array rules (minItems, maxItems, uniqueItems), and nested object structures. Schemas can also express conditional logic, composition (allOf, anyOf, oneOf), and references to reusable definitions via $ref.

Validation matters because JSON is weakly structured by nature. A JSON object can contain any key with any value, and nothing about the format itself prevents a client from sending a string where you expected a number, or omitting a required field entirely. Without validation, these malformed payloads propagate through your application until they cause a cryptic error deep in your business logic — or worse, silently corrupt data. Validating at the boundary (when data enters your system) catches these issues immediately with clear, actionable error messages rather than letting them cascade into harder-to-diagnose failures downstream.

The Ajv library that powers this validator is the most widely adopted JSON Schema validator in the JavaScript ecosystem. It is used by tools like ESLint, webpack, and the VS Code JSON language service. By running Ajv directly in your browser, you get the same validation engine used in production systems — without sending your data to any server.

JSON Schema Drafts: Draft 4 vs 6 vs 7 vs 2019-09 vs 2020-12

JSON Schema has evolved through several drafts, each adding new features while maintaining backward compatibility for the core vocabulary. Our validator supports all of them. Understanding the key differences helps you choose the right draft and interpret validation errors correctly.

Draft 4 is the oldest widely-used version and remains common in legacy systems. It supports the fundamental building blocks: types, required properties, enum, pattern, $ref references, and basic composition with allOf/anyOf/oneOf. The exclusiveMinimum and exclusiveMaximum keywords are boolean flags in this draft (set alongside minimum/maximum), which is a frequent source of confusion when moving between drafts.

Draft 6 introduced const (match exactly one value), contains (at least one array item must match), propertyNames (constrain object key names), and examples. It also changed exclusiveMinimum and exclusiveMaximum from boolean to number — so "exclusiveMinimum": 0 now means "strictly greater than zero" rather than needing both "minimum": 0 and "exclusiveMinimum": true.

Draft 7 added readOnly, writeOnly, if/then/else for conditional schemas, and the comment keyword. It is the most widely used draft in production systems today and is a safe default choice when you need broad tooling compatibility.

Draft 2019-09 was a major restructuring. It introduced vocabulary-based modularity, added unevaluatedProperties and unevaluatedItems for stricter composition validation, and replaced definitions with $defs. The unevaluatedProperties keyword solved a long-standing pain point: enforcing "no extra properties" across schemas composed with allOf, which additionalProperties could not do reliably.

Draft 2020-12 is the latest stable draft. Its biggest change is replacing the overloaded items/additionalItems pair with the clearer prefixItems (for tuple validation) and items (for the remaining elements). It also improved dynamic references with $dynamicRef and $dynamicAnchor. Use Draft 2020-12 for new projects unless you need compatibility with tools that only support older drafts.

Common Validation Errors and How to Fix Them

When validation fails, our validator shows the JSON path to the error, what was expected, what was found, and a suggested fix. Here are the errors developers encounter most often and how to resolve them:

Type mismatch. The most common error. Your schema says "type": "number" but the data contains a string like "42". This frequently happens when reading values from CSV files, query parameters, or form inputs where everything arrives as a string. The fix is either to coerce the value before validation or to use a more permissive schema that accepts both types.

Missing required property. The schema declares a property in the required array, but the data object does not include it. Check whether the property name matches exactly (JSON keys are case-sensitive) and whether the data is nested at the expected depth. A common mistake is declaring "required": ["userName"] when the data uses "username".

Additional properties not allowed. If your schema sets "additionalProperties": false, any property not explicitly listed in properties will fail validation. This is intentional — it catches typos in property names and prevents unexpected data from passing through. The fix is either to add the extra property to your schema or remove it from the data. When composing schemas with allOf, be careful: additionalProperties only knows about properties defined in the same schema object, not in sibling allOf entries. Use unevaluatedProperties (Draft 2019-09+) for composed schemas.

Pattern mismatch. The data string does not match the pattern regex. Remember that JSON Schema patterns are implicitly anchored with a partial match — the pattern "^[A-Z]" only checks that the string starts with a capital letter, not that the entire string is uppercase. If you want a full-string match, anchor both ends: "^[A-Z]+$".

Format validation failure. Keywords like "format": "email" or "format": "date-time" validate that the string matches the expected format. A common issue is using "format": "date" (expects 2024-01-15) when the data contains a full datetime (2024-01-15T10:30:00Z) — use "format": "date-time" instead.

Real-World Use Cases

API contract testing. Define your API's request and response shapes as JSON Schemas, then validate actual payloads against them in your test suite. This catches breaking changes — a renamed field, a new required property, a type change — before they reach production. Both the API producer and consumer can validate against the same schema, ensuring both sides of the contract stay in sync.

Configuration file validation. JSON Schema powers the config validation in VS Code (settings.json, launch.json), ESLint (.eslintrc.json), TypeScript (tsconfig.json), and many other tools. When you see autocomplete and error squiggles in your editor for JSON config files, that is JSON Schema validation at work. You can add the same validation to your own application's config files by writing a schema and validating on startup.

Form validation. Use a single JSON Schema as the source of truth for both frontend form validation (showing inline errors as the user types) and backend API validation (rejecting invalid submissions). Libraries like react-jsonschema-form and Ajv make this practical. When the schema changes, both validation layers update automatically.

Data pipeline validation. In ETL pipelines, validate data at each stage — after extraction, after transformation, and before loading — to catch structural errors immediately. A missing column after a CSV parse or a null value in a non-nullable field is much easier to diagnose at the point of origin than after it has propagated through three downstream systems.

How to Use This Validator

Enter your schema. Paste a JSON Schema in the left pane. You can write one from scratch or choose a sample from the dropdown — we provide schemas for user profiles, API responses, e-commerce orders, and config files.
Enter your data. Paste the JSON data you want to validate in the right pane. The data should be a valid JSON document (object, array, or primitive) that you want to check against the schema.
Review results. Validation runs automatically as you type (with a 600ms debounce). Green means valid; red means errors. Each error shows the exact JSON path, a human-readable explanation of what went wrong, the expected vs. actual values, and a suggested fix.
Choose your draft. Use the draft selector to switch between JSON Schema versions. The validator auto-detects the draft from the $schema keyword if present, or defaults to Draft 7.
Share your results. The current schema and data are encoded in the URL hash, so you can copy the browser URL to share a pre-loaded validation state with a colleague.

Related Tools

Need to create a schema from an existing JSON example? Use our JSON to Schema Generator to automatically infer a schema from your data. Want to generate test data that conforms to your schema? Try our Mock Data Generator. For structured data markup, see our JSON-LD Generator and Schema Markup Validator. To learn more about JSON Schema fundamentals, read our Complete Guide to JSON Schema.

Frequently Asked Questions

Is my data sent to a server when I validate?

No. The validator runs entirely in your browser using the Ajv library compiled to JavaScript. Your schema and data never leave your device. You can verify this by opening your browser's developer tools and checking the Network tab — no requests are made when you validate.

Which JSON Schema draft should I use for a new project?

Use Draft 2020-12 if your toolchain supports it. It has the clearest semantics, especially for array validation (prefixItems/items) and composed schemas (unevaluatedProperties). If you need broader compatibility with older tools and libraries, Draft 7 is the safest choice — it is the most widely supported draft in production systems.

Why does my schema pass validation but not work in my application?

The most common reason is a draft mismatch. If your application uses Ajv configured for Draft 7 but your schema uses Draft 2020-12 keywords like prefixItems, those keywords will be silently ignored. Make sure the $schema keyword in your schema matches the draft your application is configured to use.

Can I validate YAML data against a JSON Schema?

JSON Schema validates JSON data, not YAML directly. However, since YAML is a superset of JSON, you can convert your YAML to JSON first and then validate it. Most programming languages have libraries that parse YAML into the same data structures as JSON, making this conversion straightforward.

What is the difference between additionalProperties and unevaluatedProperties?

additionalProperties only sees properties defined in the same schema object's properties keyword. When you compose schemas with allOf, it does not know about properties defined in sibling schemas, leading to unexpected validation failures. unevaluatedProperties (available in Draft 2019-09+) is aware of all properties evaluated by any subschema, making it the correct choice for composed schemas.