JSON Schema Validator

Validate a JSON document against a JSON Schema — instant, in-browser, private

You might also need

JSON Schema Generator for Function Calling

Free online JSON schema generator for AI function calling. Build tool schemas …

JSON Validator

Free online JSON validator. Check JSON syntax and validate against JSON Schema …

JSON Formatter & Beautifier

Free online JSON formatter and beautifier. Format, validate, and minify JSON …

JSONPath Tester

Free online JSONPath tester. Evaluate JSONPath expressions against JSON data …

Structured Output Tester

Free online structured output tester. Validate JSON schemas, generate example …

What Is JSON Schema Validation?

JSON Schema is a vocabulary for describing the shape of JSON data. Instead of hoping an API payload has the right fields, you write a schema that says “this must be an object, it must have name and email, age must be an integer between 0 and 120,” and then you check documents against it. That check is JSON Schema validation, and it’s what this tool does.

The distinction that trips people up: a plain JSON validator only answers “is this syntactically valid JSON?” A JSON Schema validator answers a harder, more useful question — “does this JSON match the contract I expect?” Well-formed JSON can still be completely wrong for your application: a missing field, a string where a number belongs, an unexpected extra key. Schema validation catches all of that before the bad data reaches your code.

Paste your schema into the top panel, paste the JSON document you want to check into the panel below it, and press Validate (or Ctrl+Enter). If the document conforms, you get a green confirmation. If it doesn’t, you get a numbered list of every violation, each tagged with the exact path to the offending value.

How to Validate JSON Against a Schema

  1. Add your schema. Drop a JSON Schema into the “JSON Schema” panel. If you don’t have one, click Load Example to see a realistic user-profile schema, or generate one first with our JSON Schema Generator.
  2. Add the document. Paste the JSON you want to validate into the “JSON document” panel underneath.
  3. Read the result. Validation runs live as you type and on Ctrl+Enter. A passing document shows the detected schema draft; a failing one lists each error with its JSON path — for example .age: 130 > maximum 120 or root: missing required property "email".
  4. Fix and re-check. Correct the document (or the schema), and the result updates instantly. Use Copy to grab the report, or Ctrl+L to clear both panels.

Everything happens client-side, so you can iterate as fast as you can type. There’s no round-trip to a server and no rate limit.

Reading the Error Output

Each error line points at a specific location using dotted paths for object keys and bracket indices for array elements:

  • root: missing required property "email" — the top-level object is missing a required key.
  • .age: expected type "integer" but got "string" — a value has the wrong type. This is the single most common failure, usually because a number arrived wrapped in quotes.
  • .tags[2]: expected type "string" but got "number" — the third element of the tags array is the wrong type.
  • .role: value must be one of: ["admin","editor","viewer"] — an enum violation.
  • root: unexpected property "nickname" — the schema set additionalProperties: false and the document included a key that isn’t declared.

Because the path is explicit, you don’t have to eyeball a large payload. Search for the key and fix it.

Common JSON Schema Validation Errors

Type mismatches. JSON has no separate integer type on the wire, but schemas distinguish integer from number. A value like 3.5 fails an integer constraint. And a numeric-looking string ("42") is a string, not a number — a classic bug when data comes from form fields or query parameters.

Required vs. present-but-null. required only checks that a key exists. A property set to null still counts as present. If you want to forbid nulls, constrain the type (e.g. "type": "string" rejects null) rather than relying on required.

additionalProperties surprises. By default, extra properties are allowed. Setting additionalProperties: false locks the object down to exactly the declared keys — great for strict APIs, but it will reject any field you forgot to declare, including ones added by middleware.

Enum case sensitivity. Enum matching is exact. "Admin" will not match an enum of ["admin", "editor", "viewer"]. Normalize casing before validating, or include the variants you accept.

Broken $ref. This tool resolves local references (#/definitions/Address). Remote references to other files or URLs aren’t fetched — inline the referenced subschema, or paste the fully-dereferenced schema.

JSON Schema Drafts, Briefly

JSON Schema has evolved through several drafts: Draft-04, Draft-06, Draft-07, and the newer 2019-09 and 2020-12 releases. The good news for everyday work is that the core keywords — type, properties, required, items, enum, and the numeric and string constraints — behave the same across all of them. This validator implements that widely-shared core, which covers the schemas most teams actually ship. If your schema declares a $schema URI, the detected draft appears in the result so you can confirm you’re targeting what you think you are.

The biggest cross-draft change was how exclusiveMinimum and exclusiveMaximum work: in Draft-04 they were booleans that modified minimum/maximum, while from Draft-06 onward they became standalone numbers. This tool handles both spellings, so older and newer schemas both validate correctly.

Where JSON Schema Validation Fits

API request/response contracts. Validate incoming request bodies at the edge and outgoing responses in tests. A schema is executable documentation — it can’t drift out of date the way a wiki page does.

Config files. Application and CI config in JSON (or YAML converted to JSON) is a frequent source of “it worked on my machine” bugs. Validate config against a schema in CI and reject bad values before deploy.

LLM and function-calling output. OpenAI and Anthropic tool calls, and structured-output modes, both describe their arguments with JSON Schema. When a model returns arguments, validating them against the schema catches hallucinated or malformed fields before you act on them. If you’re building those schemas, our Structured Output Tester and JSON Schema Generator pair naturally with this validator.

Data pipelines. Validate records as they enter a pipeline so a single malformed row fails loudly instead of silently corrupting downstream aggregates.

Tips for Reliable Schemas

  • Start permissive, then tighten. Get the required keys and types right first; add ranges, patterns, and additionalProperties: false once the happy path validates.
  • Describe arrays with items. An array type with no items accepts anything. Add an items subschema so every element is checked.
  • Use enum for fixed vocabularies. It’s clearer and safer than a regex, and the error message lists the allowed values.
  • Validate the schema itself. If validation behaves strangely, confirm your schema is valid JSON first — a trailing comma or unquoted key in the schema will surface as a schema parse error here before any document check runs.

Once your document validates cleanly, run it through the JSON Formatter to pretty-print it, or use the JSON Path Tester to pull specific values out of it. And if you only need a quick “is this valid JSON?” check without a schema, the JSON Validator is the faster path.

Frequently Asked Questions

What is a JSON Schema validator?

A JSON Schema validator checks whether a JSON document conforms to the rules defined in a JSON Schema — the expected types, required properties, value ranges, string patterns, enums, and more. It's different from a plain JSON validator, which only checks that your JSON is syntactically well-formed. This tool does both: it confirms your document is valid JSON, then checks it against the schema you provide and lists every rule it violates.

Which JSON Schema drafts does this tool support?

It supports the common keyword set shared across Draft-04, Draft-06, and Draft-07, which covers the vast majority of real-world schemas: type, required, properties, patternProperties, additionalProperties, items, enum, const, minimum/maximum, minLength/maxLength, pattern, minItems/maxItems, uniqueItems, minProperties/maxProperties, multipleOf, allOf, anyOf, oneOf, not, and local $ref references. If your schema sets a $schema field, the detected draft is shown in the result.

Is my data sent to a server?

No. All validation runs entirely in your browser using JavaScript. Your schema and your JSON document never leave your machine — nothing is uploaded, logged, or stored on a server. That makes it safe to validate payloads that contain API keys, personal data, or internal fields.

Why does my JSON fail validation when it looks correct?

The most common causes are a missing required property, a type mismatch (for example a number sent as a string like "42" instead of 42), an unexpected property when the schema sets additionalProperties to false, or a value outside an enum or numeric range. The tool reports the exact JSON path of each failure, so you can jump straight to the offending field.

What's the difference between this and a JSON Schema generator?

A generator produces a schema from example data or a form. A validator does the reverse — you already have a schema, and you check documents against it. If you don't have a schema yet, build one with our JSON Schema Generator, then paste it here to validate real payloads.

Can I validate an array of objects?

Yes. Set the schema type to "array" and describe each element under "items". Constraints like minItems, maxItems, and uniqueItems apply to the array itself, while the items schema validates every element. The error output uses index notation such as [0].email so you know exactly which element failed.

Does the validator check formats like email or date?

Yes, for common formats. When a string property declares a format such as email, date, date-time, uri, uuid, ipv4, or hostname, the tool applies a practical check for that format. Unknown or exotic formats are treated as annotations and are not enforced, matching the default behavior of most schema libraries.