UUID Studio

JSON Schema Validator

Validate JSON against a schema.

  • 🔒 No data stored or uploaded
  • âš¡ 100% client-side
  • 🆓 Free, no account

Need more than one tool at a time? Open the full Workbench - or press Ctrl+K to jump to any tool.

Create or edit JSON here (syntax colors), then format, validate, or convert - same as MongoDB $binary UUID blobs on the Convert tab once detected.

New document

About JSON Schema Validator

JSON Schema validates structure rather than syntax: whether required fields are present, whether a value is the right type, whether a string matches a pattern or a number falls in a range. That is a different question from whether a document parses, and it is the one that determines whether your API can actually use the payload.

The single most surprising thing about JSON Schema is that additional properties are allowed by default. A schema listing three properties will happily validate a document containing thirty, and a typo in a field name therefore passes validation while the intended field is simply missing. Setting additionalProperties: false is what turns a schema from documentation into a contract.

The second is that required is a separate keyword from the property definitions. Listing a property under properties does not make it mandatory - it only says what shape it must have if present. Fields are optional unless named in the required array, which catches almost everyone once.

Draft versions differ in ways that break schemas silently. Draft-04 used exclusiveMaximum as a boolean alongside maximum; later drafts made it a number. id became $id, and definitions became $defs. A schema without a $schema declaration is interpreted according to whatever the validator defaults to, so declare it explicitly.

Validation runs in your browser, so a real schema and a real payload can both be tested without either being uploaded.

How to use the JSON Schema Validator

  1. Paste the schema and the document you want checked against it.
  2. Read the errors: each names the failing instance path and the keyword that failed.
  3. If a document you expected to fail passes, check additionalProperties and required - those two account for most surprises.
  4. Declare $schema in your schema so the validator uses the draft you wrote it for.

Examples

  • Instance
    {"name":"Ada","age":30}
  • Schema
    {"type":"object","required":["name"],"properties":{"name":{"type":"string"},"age":{"type":"number"}}}

JSON Schema Validator in code

The same operation this tool performs, in the languages you are most likely to need it.

JavaScript (Ajv)
import Ajv from "ajv";
import addFormats from "ajv-formats";

const ajv = new Ajv({ allErrors: true, strict: true });
addFormats(ajv);   // "format" keywords are opt-in

const schema = {
  $schema: "https://json-schema.org/draft/2020-12/schema",
  type: "object",
  properties: {
    id:    { type: "string", format: "uuid" },
    email: { type: "string", format: "email" },
    age:   { type: "integer", minimum: 0, maximum: 150 },
  },
  required: ["id", "email"],       // properties alone does NOT mean required
  additionalProperties: false,      // without this, typos pass silently
};

const validate = ajv.compile(schema);
if (!validate(data)) console.error(validate.errors);

// Compile once at startup, not per request - compilation is the
// expensive part and validation is fast.
Python (jsonschema)
from jsonschema import Draft202012Validator

validator = Draft202012Validator(schema)

# iter_errors gives all failures; validate() raises on the first
for err in sorted(validator.iter_errors(data), key=lambda e: e.path):
    print(list(err.absolute_path), err.message)

# Check the schema itself is valid before using it
Draft202012Validator.check_schema(schema)
The two defaults that surprise everyone
const schema = {
  type: "object",
  properties: { name: { type: "string" } },
};

// 1. Properties are OPTIONAL by default
validate({});                  // PASSES - name is not required
// Fix: required: ["name"]

// 2. Extra properties are ALLOWED by default
validate({ nmae: "typo" });    // PASSES - nmae is just an extra property
// Fix: additionalProperties: false

// Together these mean a schema can validate a document that has
// none of the fields you wanted and several you did not.

When you need this

  • Checking an API request or response against its documented schema.
  • Validating a config file in CI before it reaches production.
  • Finding out which specific field is causing a 422 from an API.
  • Testing a schema you are writing against known-good and known-bad examples.

Common problems and what causes them

additionalProperties allowed by default
A schema validates documents containing properties it never mentions, so a misspelled field name passes while the real field is absent. Set additionalProperties: false to make the schema an actual contract.
Properties are not required unless listed
Putting a field under properties describes its shape if present; it does not make it mandatory. Add it to the required array. An empty object validates against a schema with dozens of properties and no required list.
format not enforced by default
Keywords like format: "email" or "uuid" are annotations, not assertions, in several validators. Ajv needs the ajv-formats package before they do anything at all.
Draft version differences
exclusiveMaximum was a boolean in draft-04 and became a number later; id became $id; definitions became $defs. Without a $schema declaration the validator guesses, and a schema can behave differently than intended. Declare it.
type: integer and floats
JSON has one number type, so 1.0 is an integer by JSON Schema rules while 1.5 is not. A value arriving as 1.0 from a language that always emits a decimal point will pass type: integer, which may not be what you assumed.
Recompiling the schema per request
Compilation is the expensive step. Compiling inside a request handler adds measurable latency to every call. Compile once at startup and reuse the validator.

FAQ

Why does my schema accept a document with a misspelled field?
Because additionalProperties defaults to true, so unknown properties are permitted and the misspelled one is simply treated as extra. The intended field is then absent - and if it is not in required, that passes too. Set additionalProperties: false.
Why are my properties optional?
properties only describes shape. Mandatory fields must be listed in the separate required array. This is the most common JSON Schema misunderstanding.
Does format: "email" actually validate anything?
Not by default in several validators - format is an annotation unless format assertion is enabled. In Ajv you must install and register ajv-formats. Check your validator rather than assuming.
Which draft should I use?
2020-12 for new schemas, and declare it with $schema. Be aware that tooling support varies - some ecosystems are still on draft-07 - so check what your validator and code generators actually implement.
What is the difference between this and JSON validation?
Syntax validation asks whether a parser can read the document. Schema validation asks whether the document has the right fields, types and constraints. A perfectly valid JSON document can fail schema validation completely.
Which draft?
Draft-07 style schemas supported by Ajv.

Related reading