Skip to main content

Data & Format / JSON Tools

JSON Schema Validator

JSON Schema Validator checks a JSON document against a schema you supply, reporting each violation with the JSON path that triggered it. It supports the widely used drafts and shows nested and array-item errors, not just top-level ones. Nothing is uploaded.

Sponsored

This space is reserved for a sponsor.

Sponsored

This space is reserved for a sponsor.

How to use

  1. 1

    Paste the JSON document you want to check

    Drop the instance — an API response, a config blob, a record from a database — into the input box. The validator reads it as you type, so you see validity before you press anything. No part of the document leaves your machine at any step.

  2. 2

    Paste or write the schema

    Provide the schema in the second box. Common building blocks are type, required, properties, items, enum, pattern, minimum and format. If the schema references shared definitions with $ref pointing at #/definitions/foo, those local fragments resolve automatically.

  3. 3

    Pick the draft your schema targets

    Select the dialect that matches what you wrote. draft-07 is still the most widely deployed, but 2019-09 and 2020-12 add features such as the unevaluatedProperties keyword and a clearer split between annotation and assertion behaviour. A schema written for one draft can behave differently under another.

  4. 4

    Read the errors with their paths

    Each failure names the JSON path that triggered it, such as instance.address.city or instance.items[3].price, so you can take the message straight back to the source data. Nested objects and individual array elements are reported separately rather than collapsed into one vague top-level error.

  5. 5

    Fix and re-validate

    Correct the document or tighten the schema, then re-run. Validation is instant and local, so iterating costs nothing but a keystroke. When the output is empty, the instance satisfies every constraint the schema expresses.

Key facts

  • DraftsJSON Schema is a vocabulary, not a single fixed standard. The drafts in widest use are draft-07, 2019-09 and 2020-12; draft-07 remains the most deployed in published APIs.Source:json-schema.org drafts
  • $refA reference can target a local fragment such as #/definitions/User, which this tool resolves, or an external URL, which it cannot because that would require a network request.Source:JSON Schema Core §8
  • formatUnder the 2020-12 specification, format is an annotation by default and is not enforced unless format assertion is enabled. Libraries such as ajv follow this default.Source:JSON Schema 2020-12 §7.1
  • TypesThe supported types are string, number, integer, object, array, boolean and null. number accepts both 1 and 1.0; integer rejects any value with a fractional part.Source:JSON Schema Validation
  • PrivacyValidation runs entirely in your browser. No document, schema or error report is transmitted to any server.Source:This tool

Frequently asked questions

Which JSON Schema drafts are supported?

The validator handles the dialects you are most likely to meet in production: draft-04, draft-06, draft-07, 2019-09 and 2020-12. draft-07 remains the most common in published APIs and code generators, while the two newer drafts are IETF Internet-Drafts that introduce refinements such as unevaluatedProperties and a clearer separation between annotations (hints) and assertions (hard checks). Picking the wrong draft can make a valid document look invalid, so match the selector to whatever produced the schema.

Does it resolve remote $ref and $id references?

No network calls are made. References that point to local fragments, such as #/definitions/User or #/$defs/Address, resolve against the schema you pasted. References that point at an external URL — a shared schema hosted on another server — cannot be fetched, because doing so would mean uploading your schema and the document to that server. For an external $ref, paste the referenced schema inline (or bundle it) before validating. This is a privacy guarantee, not a missing feature.

Does the format keyword actually validate my value?

Not by default, and this surprises people. Under the 2020-12 specification the format keyword (email, date, uri, uuid and so on) is an annotation, meaning a validator may recognise it but is not required to enforce it. Many libraries, including the popular ajv engine, therefore accept "not-an-email" as a valid string unless you explicitly turn on format assertion. If you need format to reject bad values, enable assertion mode; otherwise treat a passing format check as informational rather than guaranteed.

My document looks valid but still fails. Why?

A handful of traps account for most failures. A field typed as integer rejects 1.0 and 1 because they are not whole numbers in schema terms. additionalProperties set to false rejects keys you did not list. required is checked against the object as a whole, so a missing key fails even when the present keys are perfect. enum rejects anything outside the listed set, including the right value in the wrong case. Read the path in the error — it tells you exactly which constraint fired.

Is my JSON uploaded to a server?

No. Parsing, schema loading and validation all run inside the page using the JavaScript engine your browser already has. No request leaves your machine, and the one browser interface the tool touches is the clipboard, only when you choose to copy. JSON payloads routinely carry tokens, identifiers and personal data, so a validator that round-trips your text through a backend would write it into server logs at minimum.

Related tools

Sponsored

This space is reserved for a sponsor.