JSON Schema Validator
YeniValidate JSON against a JSON Schema (draft-07 / draft-2020-12) with clear error messages.
Runs entirely in your browser. Nothing is uploaded.
What Is JSON Schema and Why Does It Matter?
JSON (JavaScript Object Notation) is the lingua franca of web APIs, configuration files, and data interchange. But raw JSON has no built-in type system — a field can be a string one day and a number the next, and the only way to discover the mismatch is a runtime crash or a subtle data bug. JSON Schema fills that gap: it is a declarative vocabulary for describing the expected structure and constraints of a JSON document, validated against actual data at runtime.
Teams use JSON Schema to validate API request payloads before processing them, to enforce the shape of configuration files loaded at startup, to auto-generate documentation and UI forms from a single source of truth, and to maintain contract consistency across microservices. OpenAPI — the standard for REST API documentation — is built directly on top of JSON Schema, making it the most widely deployed data validation standard on the web.
JSON Schema Draft Versions: Draft-07, Draft 2019-09, and Draft 2020-12
JSON Schema has gone through several specification drafts. Draft-07, released in 2018, remains the most widely supported across all mainstream validator libraries and is the dialect used by OpenAPI 3.0. It introduced the powerful if/then/else conditional validation keywords, readOnly/writeOnly property annotations, and content encoding keywords. If you are writing schemas today and do not need the newest features, Draft-07 is the safest choice for maximum ecosystem compatibility.
Draft 2020-12 is the current stable specification and introduces several significant changes: the items keyword is replaced by prefixItems for tuple validation, dynamic references use $dynamicRef instead of $recursiveRef, and the new unevaluatedProperties and unevaluatedItems keywords provide more precise control over additional content. Use Draft 2020-12 only if you are on OpenAPI 3.1 or need those specific features — the broader validator ecosystem is still catching up to full support.
Key JSON Schema Keywords Explained
The type keyword enforces a data type: string, number, integer, boolean, array, object, or null. required lists the properties that must be present in an object. properties maps each property name to its own sub-schema. pattern applies a regular expression to a string value. minimum, maximum, minLength, and maxLength constrain numeric and string ranges. enum restricts a value to a fixed set of allowed values; const restricts it to a single value.
Composition keywords let you build complex rules from simple building blocks: allOf acts like logical AND, anyOf like OR, and oneOf like XOR. The not keyword inverts a schema. The if/then/else keywords enable conditional validation — different rules apply depending on whether the data satisfies the if schema. Together these let you express nearly any validation rule without writing custom imperative code.
JSON Schema in Production: API Contracts and CI Pipelines
In production systems, JSON Schema validation runs server-side or in CI pipelines using libraries like Ajv (JavaScript/Node.js), jsonschema (Python), or Newtonsoft.Json (C#). Schemas are committed to version control alongside application code so that contract changes are reviewed and tracked like any other change. Breaking changes — removing a required field, narrowing a type — are caught in code review before they reach production and break consumers.
This browser-based tool is ideal for designing and debugging schemas iteratively before committing them. Paste your data, write your schema, click Validate, read the detailed error messages, and refine — no server, no npm install, no round trips. The validator also pretty-prints your JSON on each validation run, making it a convenient combined JSON formatter and schema tester. Once your schema is validated here, drop it directly into your OpenAPI spec or application configuration.
Practical Example: Validating an API Response
Suppose your API returns a user object. A JSON Schema that validates it might require an integer id, a non-empty string name, a string email matching an email pattern, and an optional string role from an enum of 'admin', 'editor', and 'viewer'. Setting additionalProperties to false ensures your API never silently returns undocumented fields that downstream consumers might inadvertently depend on.
The if/then/else feature enables conditional rules — for example, if the role is 'admin' then a permissions array is required, otherwise it is forbidden. These compositional rules let a single schema cover multiple valid shapes of an object without duplicating property definitions. Writing and testing that schema here before embedding it in your codebase saves significant debugging time in production. Use the built-in example presets (User Profile, Product, Address) to get started instantly.
How UtiloKit Compares to Other JSON Schema Validators
Most online JSON Schema validator tools fall into two categories: visual schema builders and server-side API validators. jsonschema.net forces you through a point-and-click UI to construct schemas — it's helpful for beginners learning schema structure, but slow for developers who already know what keywords they need and just want to test a schema they've written. You can't paste raw Draft-07 JSON directly and iterate fast.
jsonschemavalidator.net, built on Microsoft's Newtonsoft.Json library, reports errors using .NET property paths and error codes that look unfamiliar to JavaScript developers. The error messages are correct but framed around the .NET object model, not the JSON pointer paths your Node.js code will see. Tools like Stoplight and SwaggerHub validate schemas as part of a full OpenAPI document and require a project setup and account.
UtiloKit's validator runs on the same Ajv engine that powers most Node.js, Express, and Fastify applications. The error messages, JSON pointer paths, and keyword behavior match your production environment exactly — and it runs free in your browser with no account, no upload, no file size limit, and no daily usage cap.
A Brief History of JSON Schema: From IETF Draft to De Facto Standard
JSON itself was formalized by Douglas Crockford and published in 2001, originally as a lightweight data interchange format extracted from JavaScript. It quickly displaced XML in web APIs because of its minimal syntax and direct mapping to common data structures. But JSON's simplicity was also a limitation: the format has no native type system, no built-in constraints, and no way to describe what a valid document looks like. That gap led to the creation of JSON Schema. Kris Zyp authored the first JSON Schema specification in 2009 as an IETF Internet Draft, providing a vocabulary for annotating and validating JSON documents using JSON itself — no new syntax required.
Since 2009, JSON Schema has progressed through several incompatible specification drafts. Draft-03 (2010) and draft-04 (2013) established the foundational keyword set and introduced the $ref referencing mechanism. Draft-06 and draft-07 (2017–2018) refined type-specific keywords and added if/then/else conditional validation. Draft 2019-09 reorganized the specification into a modular vocabulary and introduced $anchor for named anchors. Draft 2020-12 — the current recommended version — replaced the items tuple form with prefixItems, introduced $dynamicRef for recursive schemas, and added unevaluatedProperties and unevaluatedItems for more precise closed-schema semantics. The $schema keyword at the root of a document identifies which draft a schema targets — for example, "$schema": "https://json-schema.org/draft/2020-12/schema" — allowing validators to apply the correct dialect rules.
Despite draft 2020-12 being the current spec, draft-07 remains the most widely implemented version in practice. The broader ecosystem — Ajv in JavaScript, jsonschema in Python, Newtonsoft.Json in C#, and the OpenAPI 3.0 Specification — standardized on draft-07 and the migration cost of upgrading large schema libraries is high. It is important to note that JSON Schema carries IETF Internet Draft status, meaning it is not yet a formal RFC standard. Nevertheless it functions as a de facto standard for JSON data validation: it is embedded in OpenAPI, referenced in VS Code's IntelliSense engine, used by AWS CDK, and validated in CI pipelines at most large technology companies. The JSON Schema organization maintains the specification at json-schema.org under an open governance model.
Core JSON Schema Keywords: A Practical Reference
The type system in JSON Schema covers seven primitive types: string, number, integer, boolean, object, array, and null. The type keyword can accept a single string or an array — "type": ["string", "null"] is the standard pattern for nullable fields, making it explicit that a field may legitimately be absent or null rather than requiring a value. Object validation uses properties to define per-property sub-schemas, required to list mandatory property names, and additionalProperties to control unknown keys. Setting additionalProperties: false creates a "closed" schema that rejects any property not explicitly listed under properties — the strictest contract for API payloads. patternProperties maps regex patterns to sub-schemas for dynamically named keys. minProperties and maxProperties constrain how many keys an object may carry.
Array validation uses items (draft-07) or prefixItems (draft 2020-12) for per-element sub-schemas. When items is a single schema, every element must satisfy it — useful for homogeneous lists. When items is an array of schemas in draft-07, each position is validated against the corresponding schema — this is tuple validation, where order matters. minItems and maxItems bound array length; uniqueItems: true enforces set semantics. String validation keywords include minLength, maxLength, and pattern for regex constraints. The format keyword provides semantic hints — values like "email", "date-time", "uri", and "ipv4" — but is only an annotation by default. Validators must be explicitly configured to enforce format (in Ajv, pass { formats: "full" } or install ajv-formats). Number validation uses minimum, maximum, exclusiveMinimum, exclusiveMaximum, and multipleOf for divisibility constraints.
The composition keywords are what give JSON Schema its expressive power. allOf requires the data to satisfy every listed sub-schema simultaneously — a logical AND, often used to layer base schemas with extension schemas. anyOf requires at least one sub-schema to pass — logical OR, used for union types. oneOf requires exactly one sub-schema to pass — logical XOR, useful when sub-schemas are mutually exclusive and you want to flag ambiguous inputs. The not keyword inverts a sub-schema result, enabling exclusion patterns. $ref references a sub-schema defined elsewhere in the document — typically under $defs (draft 2020-12) or the legacy definitions key — keeping schemas DRY and modular. Together these primitives allow you to express precisely any structural rule that could otherwise require hundreds of lines of imperative validation code.
Ajv, the Validator Ecosystem, and JSON Schema Beyond JavaScript
Ajv (Another JSON Validator), created by Evgeny Poberezkin and released as open source, is the fastest and most widely used JavaScript JSON Schema validator. Its key architectural innovation is just-in-time compilation: Ajv compiles a schema into a native JavaScript function the first time it is used, meaning subsequent validations against the same schema incur virtually no parsing overhead. Benchmarks consistently show Ajv processing approximately one million validations per second for typical schemas on commodity hardware. Ajv supports draft-07 through draft 2020-12 and is the validation engine embedded in Fastify's built-in schema support, in the AWS CDK construct library, and in the OpenAPI tooling ecosystem. Starting with Ajv v8, strict mode is enabled by default — it rejects schemas containing unknown keywords, ambiguous exclusiveMinimum usage, and patterns that often signal a mistake, making it significantly harder to ship a silently broken schema to production. The UtiloKit JSON Schema validator runs on Ajv in the browser via its UMD build, so validation results here match precisely what your Ajv-powered backend will produce.
JSON Schema validation is not limited to JavaScript. Python developers use the jsonschema library (maintained by Julian Berman), which supports drafts 3 through 2020-12 and integrates cleanly with FastAPI's data validation layer. Java has two major implementations: everit-org/json-schema and networknt/json-schema-validator, the latter being the more actively maintained and draft 2020-12 compliant option used in enterprise Spring Boot services. Go developers use qri-io/jsonschema and xeipuuv/gojsonschema. .NET has Newtonsoft.Json.Schema and the newer JsonSchema.Net. Each language implementation has minor behavioral differences — particularly around the optional format keyword and error message structure — which is why testing schemas against the specific validator library your production stack uses is the only reliable way to confirm behavior.
JSON Schema has also become a critical piece of developer tooling beyond runtime validation. VS Code and other editors read the $schema field in files like package.json, tsconfig.json, GitHub Actions workflow files, and AWS CDK outputs to provide real-time IntelliSense, autocompletion, and inline error highlighting as you type. OpenAPI 3.0 uses a JSON Schema subset — called the OpenAPI Schema Object — for request and response definitions; OpenAPI 3.1 aligns fully with draft 2020-12. API contract testing tools like Dredd, Spectral, and Pact use JSON Schema to assert that live API responses conform to documented contracts, catching regressions automatically in CI. TypeScript code generation tools like quicktype and json-schema-to-typescript generate TypeScript interface definitions from a JSON Schema, keeping runtime validation and compile-time types in sync from a single source of truth. Even database engines have adopted the format: PostgreSQL 14+ can validate jsonb columns against a JSON Schema expression, and MongoDB implements a MongoDB-flavored JSON Schema dialect for collection-level schema validation — meaning the same schema vocabulary you test here flows through the entire stack, from IDE autocomplete to API gateway to database storage.
Frequently asked questions
What is JSON Schema?
JSON Schema is a declarative vocabulary for annotating and validating JSON documents. It defines the expected structure, data types, and constraints a JSON document must satisfy. Teams use it to validate API request and response payloads before processing them, to enforce configuration file structure, to auto-generate documentation and UI forms, and to ensure data consistency across microservices. OpenAPI 3.0 and 3.1 are both built on top of JSON Schema, making it the most widely deployed data validation standard on the web today.
Which JSON Schema draft does this validator support?
This validator implements the core keywords from JSON Schema Draft-07, the most widely supported version across all major validator libraries including Ajv (JavaScript), jsonschema (Python), and Newtonsoft.Json (C#). Draft-07 introduced if/then/else conditional validation, readOnly/writeOnly annotations, and content encoding keywords. Draft 2020-12 is the newest spec but is only needed if you use OpenAPI 3.1 or the prefixItems tuple syntax. For most real-world use cases in 2026, Draft-07 covers everything you need.
What is the difference between allOf, anyOf, and oneOf?
allOf requires the data to be valid against every listed sub-schema — it acts like a logical AND. anyOf requires validity against at least one sub-schema — logical OR. oneOf requires validity against exactly one sub-schema — logical XOR. These composition keywords let you build complex validation rules from simple reusable pieces and are central to how OpenAPI specifications define request and response bodies. Most other online validators like jsonschema.net expose a click-through UI that obscures these composition keywords — this tool lets you write and test raw schema JSON directly.
How do I reference a sub-schema with $ref?
Define reusable schemas in a top-level $defs object (or the older definitions object for compatibility), then reference them with '$ref': '#/$defs/SchemaName'. This keeps your schema DRY and readable. This validator supports local (same-document) $ref only — remote $ref URLs pointing to external files are not fetched. For most practical schemas, local $ref is sufficient. Tools like Postman support remote $ref but require a full project setup and account login; this tool validates instantly with no configuration.
What does additionalProperties: false do?
It forbids any property in the object that is not explicitly listed under the properties keyword. This creates a closed schema — very useful for strict API contracts where unexpected fields should cause a validation failure. If you want to allow extra properties but only validate the ones you know about, omit additionalProperties or set it to true. This is one of the most common gotchas: if you add a new property to your data without updating the schema, validation will fail until additionalProperties is set correctly.
Can I validate arrays of objects?
Yes. Set type to 'array' and provide an items sub-schema. Every element in the array will be validated against that sub-schema. For tuple validation — where each position has its own schema — set items to an array of schemas in Draft-07 (or use prefixItems in Draft 2020-12). You can also constrain array length with minItems, maxItems, and enforce uniqueness with uniqueItems: true. Array validation here behaves the same way as Ajv handles it in Node.js, so schemas you test here will behave the same way in production.
What is if/then/else in JSON Schema?
Conditional validation introduced in Draft-07: if the data is valid against the if schema, it must also be valid against the then schema; otherwise it must be valid against the else schema. This is more readable than using anyOf with duplicated constraints and is ideal for schemas where one field's type determines the allowed values of another field — for example, a payment object where creditCard type requires a cardNumber field while bankTransfer type requires a routingNumber field instead.
What are the most common JSON Schema validation errors?
The most common errors are: missing required properties (a field listed in required is absent from the data), type mismatches (a field is a string when the schema expects a number), pattern violations (a string fails a regex in the pattern keyword), range violations (a number is outside minimum/maximum bounds), and additional property errors (an unexpected field is present when additionalProperties is false). This validator reports each error with the exact JSON pointer path to the failing data, so you can fix issues quickly without guessing which field caused the problem.
How is JSON Schema used in OpenAPI / Swagger?
OpenAPI 3.0 uses a superset of JSON Schema Draft-07 to define the structure of request bodies, response payloads, query parameters, and headers. OpenAPI 3.1 aligns fully with JSON Schema Draft 2020-12. Writing schemas in this tool is an ideal way to prototype and debug schemas before embedding them in an OpenAPI specification. Tools like Swagger Editor and Stoplight validate your full OpenAPI document but require you to have the complete spec ready — this tool lets you test a single schema component in isolation, which is much faster for iterative development.
What is the difference between type: 'number' and type: 'integer'?
In JSON Schema, 'number' accepts any numeric value — integers and floats (e.g., 42 and 3.14 both pass). 'integer' accepts only whole numbers — 42 passes but 3.14 fails. Use 'integer' when a field must be a count, ID, or index that can never have a decimal component. This distinction matters for API contracts: if your backend stores a price as a float but your schema requires 'integer', you will get a runtime validation error in production on the first fractional price.
Can I use pattern to validate email addresses or URLs?
Yes. The pattern keyword accepts a regular expression and validates that the string matches it. For emails, a simple pattern like '^[^@]+@[^@]+\.[^@]+$' catches obvious format errors. For stricter validation, JSON Schema Draft-07 also has a format keyword with values like 'email', 'uri', and 'date-time', though format validation is optional per the spec and must be explicitly enabled in validators like Ajv. Unlike some online validators that silently ignore the format keyword, this tool lets you test both pattern and format constraints so you know exactly which one to rely on in your stack.
Why does the validator pretty-print my JSON on validate?
The validator parses your JSON input and re-serializes it with 2-space indentation for readability. This also serves as a quick JSON formatter — if the re-formatting succeeds, your JSON is syntactically valid. If the JSON cannot be parsed, the validator reports a parse error before attempting schema validation. This is the same approach Ajv uses internally: parse first, validate second. If you just need to check whether a JSON document is syntactically valid, the re-print step alone will tell you — no schema required.
What is the difference between JSON Schema and TypeScript types?
TypeScript types are checked at compile time and are erased at runtime. JSON Schema is validated at runtime against actual data values, making it essential for validating external input — API responses, user-submitted data, config files — that TypeScript cannot check. Tools like json-schema-to-typescript and zod can generate one from the other, but they serve complementary purposes in a production system. A common pattern is to write a JSON Schema for your API contract, use this tool to validate it, and then generate TypeScript types from the schema so your code and runtime validation stay in sync.
Does this validator support the 'not' keyword?
Yes. The 'not' keyword inverts the result of a sub-schema: if data is valid against the not schema, validation fails. This is useful for excluding specific values (e.g., not: { const: 'admin' } to forbid the string 'admin') or for excluding a type from a union. The 'not' keyword works in combination with composition keywords — for example, not + anyOf lets you express 'must be a string but not one of these specific values'. This is fully supported and behaves the same way as Ajv's not keyword implementation.
How do I validate that a string matches a specific date format?
Use the format keyword with value 'date' (YYYY-MM-DD) or 'date-time' (ISO 8601 with time). Alternatively, use the pattern keyword with a regex like '^\d{4}-\d{2}-\d{2}$' for strict enforcement. The format keyword signals intent but some validators require explicit opt-in to actually enforce it — the pattern approach guarantees enforcement regardless of validator settings. This tool applies format validation when you use it, giving you a true preview of what Ajv would do with ajv.options.formats = 'full'.
How does this compare to jsonschema.net and jsonschemavalidator.net?
jsonschema.net forces you to build your schema through a visual point-and-click UI rather than writing raw JSON — useful for learning but slow for real work. jsonschemavalidator.net is powered by Newtonsoft.Json and reports errors in a .NET-centric format that doesn't always match JavaScript behavior. This tool runs on the same Ajv library used by most Node.js applications, so the validation results you see here match exactly what your production backend will see — without any account, upload, or install.
Related tools
Tüm araçları görüntüle
Yeni CSS Küçültücü
Yorumları ve gereksiz boşlukları kaldırarak CSS'yi küçültün.
Yeni JSON Kaçış / Geri Dönüşüm
Ham metni JSON güvenli bir dizeye dönüştürün ve geri çözün.
Yeni HTTP Durum Kodları
HTTP durum kodlarının sade açıklamalarıyla aranabilir referansı.
Yeni Regex Kopya Kağıdı
Düzenli ifade belirteçleri ve bayraklarının aranabilir referansı.
Yeni ASCII Tablosu
Onluk, onaltılık, sekizli ve ikili karakter kodlarının aranabilir tablosu.
Yeni PX'ten REM'e Dönüştürücü
Kök font boyutuna göre px, rem, em ve pt arasında dönüştürün.