JSON Schema Standard: One Dialect or Many?

Updated 5 November 2026 · Standard formula, shown below

No, the JSON Schema standard is not a single dialect; it is a family of specifications that has evolved through several versions, with the current release being JSON Schema 2020-12. While the core vocabulary remains consistent, each draft introduces changes, deprecations, and new keywords, meaning a schema written for one version may not validate identically under another. This article explains the differences, how to choose a version, and what it means for your data validation.

Background: The Evolution of JSON Schema

JSON Schema began as an informal proposal in 2007 by Kris Zyp, with the goal of providing a way to describe and validate JSON data structures. It gained traction and was eventually submitted to the IETF, leading to a series of formal drafts. Each draft is designed to be backward-compatible in spirit but not always in practice. The major milestones are:

Draft 3 (2009): The first widely adopted version, introducing keywords like required, additionalProperties, and dependencies.
Draft 4 (2013): A significant rewrite that clarified the specification, removed some keywords, and changed the meaning of required from an array to a boolean (later reverted).
Draft 6 (2018): Added const and contains, and introduced the id keyword for referencing.
Draft 7 (2018): Added if/then/else conditionals and readOnly/writeOnly for API documentation.
2019-09: A major restructuring, introducing the concept of vocabularies and the $vocabulary keyword, allowing custom extensions.
2020-12: The current stable version, which refined the meta-schema, added prefixItems for tuple validation, and clarified the behavior of $dynamicRef.

Each version is a separate dialect with its own meta-schema, and a validator must explicitly declare which version it supports.

How the Versions Differ

While the core principles of JSON Schema remain the sameâ€”describing the structure, types, and constraints of JSON dataâ€”the specifics vary. Key differences include:

Keyword changes: For example, dependencies in Draft 3 was replaced by dependentSchemas and dependentRequired in 2019-09.
Schema referencing: The $id and $ref semantics changed, especially with the introduction of $dynamicRef in 2020-12 to handle recursive schemas.
Validation behavior: The exclusiveMinimum and exclusiveMaximum changed from boolean modifiers to numeric values in Draft 6.
Meta-schema location: Each version has a distinct URI (e.g., http://json-schema.org/draft-07/schema vs. https://json-schema.org/draft/2020-12/schema).

These differences mean that a schema written for Draft 4 might fail to parse or validate correctly in a Draft 7 validator, even if the data is the same.

How to Choose a Version

When starting a new project, you should use the latest stable version (2020-12) unless you have a specific reason not to. However, there are practical considerations:

Tooling support: Some validators and code generators may not yet fully support 2020-12. Check your language’s library ecosystem.
Legacy schemas: If you have an existing schema library, you may need to stick with the version they were written for to avoid breaking changes.
Interoperability: If you’re exchanging schemas with external partners, agree on a common version to avoid validation discrepancies.
Specific features: If you need conditional validation, Draft 7 introduced if/then/else, which is simpler than the Draft 4 approach using allOf and not.

In practice, Draft 7 is still widely used because of its balance of features and tool support, but 2020-12 is the recommended choice for new work.

Common Problems and Misconceptions

One of the most common issues is assuming that all JSON Schema validators are interchangeable. Even for the same version, implementations may have bugs or missing features. Another misconception is that JSON Schema is a complete data modeling language; it lacks features like inheritance or custom types, and it is not designed for relational data. Also, many people confuse JSON Schema with JSON Patch or JSON Pathâ€”they are separate specs for different purposes.

Another frequent problem is the type keyword. In JSON, numbers can be integers or floats, but JSON Schema’s integer type only matches numbers without a fractional part. A value like 1.0 is considered an integer in JSON Schema, which surprises some developers.

Comparisons with Other Validation Approaches

JSON Schema is not the only way to validate JSON data. Alternatives include:

Hand-written validation code: More flexible but harder to maintain and not portable.
TypeScript or other static type systems: Provide compile-time checks but only for code, not for runtime data from external sources.
XML Schema (XSD): More powerful for complex document structures but much more verbose and not JSON-native.
OpenAPI (formerly Swagger): Uses JSON Schema as a subset for describing API request/response bodies, but adds its own constraints.

JSON Schema’s main advantage is its declarative nature and portabilityâ€”the same schema can be used for validation, documentation, and code generation across many languages.

Costs and Benefits of Using JSON Schema

The primary cost is the learning curve and the need to keep up with version changes. Additionally, complex schemas can become hard to read and debug. However, the benefits are substantial:

Consistency: A single schema ensures data conforms to the same rules everywhere.
Documentation: Schemas serve as executable documentation.
Automated testing: You can generate test data from schemas.
Interoperability: Schemas are language-agnostic.

For most projects, the benefits outweigh the costs, especially when dealing with public APIs or data exchange between teams.

Safety and Best Practices

When using JSON Schema, there are a few safety considerations:

Billion Laughs attack: Be cautious with deeply nested or recursive schemas; some validators may be vulnerable to resource exhaustion. Use limits on nesting depth if possible.
Regular expressions: The pattern keyword uses ECMA-262 regex, which can be complex. Avoid catastrophic backtracking patterns.
Always specify the version: Include the $schema keyword at the top of your schema to avoid ambiguity.
Validate your schema: Use a meta-schema validator to ensure your schema is syntactically correct before using it.

Frequently Asked Questions

Is JSON Schema a standard?

Yes, but it’s an IETF Internet Draft, not a full RFC. The latest version, 2020-12, is published as a set of Internet-Drafts, and the community treats it as a de facto standard.

Can I use JSON Schema for YAML or XML?

JSON Schema is designed for JSON, but since YAML is a superset of JSON, you can validate YAML by converting it to JSON first. For XML, you would use XSD instead.

What is the difference between `allOf`, `anyOf`, and `oneOf`?

allOf requires the data to validate against all subschemas; anyOf requires at least one; oneOf requires exactly one. For example, a schema with anyOf for type string or number would accept both, while oneOf would reject a value that matches both (which is impossible for type, but possible for other constraints).

How do I reference another schema?

Use the $ref keyword with a JSON Pointer or a URI. For example, "$ref": "#/definitions/address" references a local definition. With $id, you can create portable references across files.

Does JSON Schema support inheritance or polymorphism?

Not directly, but you can simulate it using allOf to combine schemas. For example, a base schema for a person and a derived schema for an employee can use allOf to include the base properties.

What is the `additionalProperties` keyword?

It controls whether properties not defined in the properties keyword are allowed. If set to false, any extra property causes validation to fail. If set to a schema, extra properties must validate against it.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.