JSON Schema Validator: Validate JSON Against Draft 2020-12

A JSON Schema validator answers a question a syntax checker was never built to answer: not “does this parse,” but “does this parsed document have the fields, types, and constraints I actually need?” If you're not sure which of those two questions you're actually asking, Is My JSON Valid? covers that distinction in depth — this page picks up from there and assumes the syntax is already clean.

JSON Schema is the vocabulary for describing a document's required shape — properties, types, numeric ranges, string patterns, enums — as its own JSON document, so tooling checks a payload automatically instead of everyone reading the API docs and hoping.

JSON Schema has gone through several drafts, and most competing tools list draft support — 4, 6, 7, 2019-09, 2020-12 — as a checkbox without explaining why the latest one matters. Three changes from earlier drafts are worth knowing if you're maintaining schemas written against an older version:

• prefixItems replaces items/additionalItems for tuples. Fixed-position array validation — “the first element is a string, the second a number” — now uses prefixItems, freeing itemsto mean only “everything after the fixed positions,” which is a clearer split than the old dual-purpose items keyword.
• $dynamicRef/$dynamicAnchor replace $recursiveRef/$recursiveAnchor. Both express a self-referencing schema — useful for recursive structures like a tree or a nested comment thread — but the dynamic pair is more flexible about which schema in a reference chain actually gets used at resolution time.
• unevaluatedProperties is its own required vocabulary.Rather than being bundled implicitly with core validation, it now has to be explicitly declared as supported — it asks “after every applicable subschema has run, is this property still unaccounted for,” which matters once allOf/oneOf compose several schemas together.

Draft 2020-12 is also the version OpenAPI 3.1 adopted directly, which is the practical reason most new schemas should target it rather than an older draft.

One schema, describing an order object with a required ID and a non-negative total:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "orderId": { "type": "string" },
    "total": { "type": "number", "minimum": 0 },
    "status": { "type": "string", "enum": ["pending", "paid", "cancelled"] }
  },
  "required": ["orderId", "total", "status"]
}

A document that passes:

{ "orderId": "ord_492", "total": 84.5, "status": "paid" }

A document that fails, and why:

{ "orderId": "ord_493", "total": -12, "status": "shipped" }

/total   minimum: -12 is less than the minimum 0
/status  enum: "shipped" is not one of "pending", "paid", "cancelled"

/total and /status are JSON Pointers — slash-separated paths into the document, each one naming the exact value that failed rather than making you re-scan the whole payload. A JSON Pointer error path is the schema-validation equivalent of a line-and-column error from a syntax check: it tells you precisely where to look, just addressed by structure instead of by character position.

An online check is right for a one-off paste. The moment validation needs to run in a request handler, a test suite, or a CI step, you want it in code — these are the two most common libraries for it.

JavaScript: ajv

import Ajv from "ajv";

const ajv = new Ajv({ allErrors: true });
const validate = ajv.compile(schema);

const valid = validate(data);
if (!valid) {
  console.log(validate.errors);
  // [{ instancePath: "/total", message: "must be >= 0", ... }, ...]
}

Python: jsonschema

from jsonschema import Draft202012Validator

validator = Draft202012Validator(schema)
errors = sorted(validator.iter_errors(data), key=lambda e: e.path)

for error in errors:
    print(list(error.path), error.message)
# ['total'] -12 is less than the minimum of 0

Both libraries report every failure at once rather than stopping at the first one — the same behavior GenKitLab's JSON Schema Validator uses, since fixing violations one round-trip at a time is the slow way to do this. It checks a document against draft 2020-12, locates every failure by JSON Pointer the same way as the example above, and lists any schema keyword it doesn't support instead of silently skipping it — a validator that quietly ignores a keyword will tell you “valid” for data the real one would reject.

Syntax first, schema second: a document has to parse before there's anything to check against a schema at all. If you landed here without first confirming the JSON itself parses, the JSON Formatter settles that in one paste — its full guide covers every syntax rule in depth. Once the syntax is clean, bring the schema and the document to GenKitLab's JSON Schema Validator for the structural check.