JSON Schema Validator

What Is a JSON Schema Validator?

A JSON Schema Validator checks a JSON instance against a schema so developers can verify required properties, data types, string formats, numeric ranges, array rules, object structures, enums, composition keywords, and conditional rules before data enters an API, database, workflow, or application.

JSON Schema is not JSON syntax validation. JSON syntax validation asks whether text is parseable JSON. JSON Schema validation asks whether that parsed value satisfies a contract — a precise machine-readable description of the shape, types, and constraints your data must meet. Both checks are necessary, and confusing them is one of the most common developer mistakes in data validation workflows.

How ToolsSonic's JSON Schema Validator Works

Separate schema and instance panels. The two-panel workspace prevents the most common confusion — accidentally pasting the schema where the data should go. The Schema panel accepts any JSON Schema object or boolean schema. The Instance panel accepts any JSON value: object, array, string, number, boolean, or null.

Draft 4, 6, 7, and 2020-12 common subset. The Draft selector context tells you which vocabulary is in play. The local engine validates all keywords common across these drafts, with Draft 4 boolean exclusiveMinimum and exclusiveMaximum handled distinctly from the Draft 6+ numeric forms.

Path-aware error cards. Every error shows three pieces of information: the instance path such as $.user.email or $.items[0].price, the schema keyword that triggered the failure such as required, type, format, or additionalProperties, and a schema path showing where in the schema the rule lives. This is the same information Ajv provides in its error objects — formatted for humans rather than machines.

Validate as you type. The validator re-runs automatically as you edit either panel. Every keystroke triggers a fresh validation so you see errors disappear in real time as you correct the instance or refine the schema. Uncheck "Validate as you type" or use Ctrl+Enter for manual control on large documents.

Stop after first error. Enable this mode when you want to fix one error at a time instead of seeing all failures simultaneously — useful for schema development when you are working through requirements in sequence.

Common format checks. Enable "Check common formats" to activate practical checks for email, date, time, date-time, URI, uri-reference, hostname, IPv4, IPv6, and UUID. Format validation is opt-in per the JSON Schema specification — unknown formats pass silently rather than causing false failures.

Local $ref resolution. References beginning with # are resolved against the supplied schema document using JSON Pointer traversal. Both definitions (Draft 4–7) and $defs (2020-12) paths are supported. Remote HTTP references are not fetched, and each unresolved external reference is surfaced as a warning card so you know exactly which references need to be resolved before production use.

Six live statistics. The stats strip shows schema keyword count, instance node count, error count, warning count, maximum nesting depth, and draft — updating after every validation run.

Copy and download reports. The plain-text report includes the draft, timestamp, status, error count, warning count, and every finding with its path, keyword, message, and schema path. Save it as a file for QA tickets, debugging sessions, or peer review.

Common use cases

• Validating an API response body against a contract schema before parsing it in application code
• Checking configuration files and environment payloads for required fields and correct types
• Testing request and webhook fixture JSON during development without running a server
• Finding missing properties and wrong data types at precise JSON paths such as $.order.items[0].sku
• Checking email, date-time, UUID, URI, and hostname formats in a JSON payload
• Verifying array uniqueItems, minItems, maxItems, and contains rules
• Testing allOf, anyOf, oneOf, not, and if/then/else composition schemas interactively
• Reviewing local $ref definitions without uploading private or proprietary schemas
• Validating OpenAPI request and response payload objects against a schema component
• Downloading a validation report for QA documentation and debugging evidence

Why use ToolsSonic's JSON Schema Validator?

ToolsSonic's JSON Schema Validator delivers path-aware errors with schema keyword labels that competing tools omit entirely. The only directly comparable free tool — jsonschemavalidator.net — sends both schema and instance to a server via a POST API; ToolsSonic keeps everything in browser memory. Code Beautify's JSON schema validator page returns a 404. JSON Formatter & Validator is syntax-only with no schema keyword support at all. ToolsSonic combines approachable dual-panel UI, Draft 4/6/7/2020-12 support, full type/object/array/string/number/composition/conditional/format/local-ref coverage, six live stats, session history, Paste buttons, file input for both panels, a copy/download report, honest limitation messaging, privacy by architecture, and full dark mode — all running in the browser without an account, install, or server.

JSON Schema Keywords Reference — What Each Keyword Validates

Understanding the most-used JSON Schema keywords helps you write schemas that catch real data problems rather than letting invalid values slip through silently.

type validates the JSON data type. Allowed values are object, array, string, number, integer, boolean, and null. You can specify an array of types: "type": ["string", "null"] accepts either a string or a null value — useful for nullable fields.

required lists property names that must be present in an object. "required": ["id", "email"] fails with a clear required error for each missing property, identified at the instance path where the object lives.

properties defines sub-schemas for named object properties. Each key in the properties object is a property name; its value is the schema that property's value must satisfy. Properties not listed here are still allowed unless additionalProperties says otherwise.

additionalProperties controls extra properties. Set it to false to disallow any property not listed in properties or matched by patternProperties. Set it to a schema to require that additional properties satisfy that schema.

patternProperties applies sub-schemas to properties whose names match a regular expression. "patternProperties": { "^S_": { "type": "string" } } requires all properties starting with S_ to be strings.

allOf / anyOf / oneOf are composition keywords. allOf requires all listed sub-schemas to pass. anyOf requires at least one to pass. oneOf requires exactly one to pass.

not inverts a schema. "not": { "type": "string" } fails if the value is a string.

if / then / else applies conditional validation. If the if schema passes, the then schema is also validated. If if fails, the else schema is validated instead.

enum restricts a value to a fixed list. "enum": ["admin", "member", "viewer"] fails if the value is not in the list.

const restricts a value to a single fixed value — useful for discriminator fields.

format annotates a string with a semantic type. Common values include email, date-time, date, time, uri, hostname, ipv4, ipv6, and uuid. Format validation is opt-in — enable "Check common formats" in the settings bar to activate it.

$ref references another schema by JSON Pointer. Local references such as "$ref": "#/definitions/Address" are resolved against the supplied schema. Remote URLs are not fetched — they appear as warning cards.

JSON Schema Draft Versions Explained — Draft 4, 6, 7, and 2020-12

JSON Schema has evolved through several published drafts. Knowing which draft your schema targets helps you use the right keywords and interpret validator results correctly.

Draft 4 (2013) is the oldest widely deployed version. It introduced the core validation keywords — type, properties, required, additionalProperties, items, minItems, maxItems, uniqueItems, minimum, maximum, pattern, enum, allOf, anyOf, oneOf, not, and $ref. In Draft 4, exclusiveMinimum and exclusiveMaximum are booleans that modify minimum and maximum rather than numeric values of their own.

Draft 6 (2017) changed exclusiveMinimum and exclusiveMaximum to standalone numeric keywords, making the schema easier to read. It added const for single-value constraints, contains for arrays, propertyNames for object key validation, and extended $ref semantics.

Draft 7 (2018) added if/then/else for conditional validation, readOnly/writeOnly for documentation annotations, and $comment for schema authors. It is the most widely implemented version — Ajv, JSON Schema Online Validator, and most validation libraries default to Draft 7.

Draft 2019-09 and 2020-12 restructured the specification into multiple separate vocabulary metaschemas. definitions was renamed $defs. $ref no longer stops other keywords from being evaluated alongside it. unevaluatedProperties and unevaluatedItems were added for more precise control. The ToolsSonic validator supports the common keyword subset of 2020-12 — the keywords that work the same way across all drafts — and reports limitations honestly rather than silently mishandling newer semantics.

Choosing a draft: Use Draft 7 for maximum compatibility with existing tooling, libraries, and documentation. Use 2020-12 vocabulary when you are writing new schemas that will be validated by a fully conformant implementation and need unevaluatedProperties or dynamic references. The $schema keyword inside your schema document — for example "$schema": "http://json-schema.org/draft-07/schema#" — identifies the intended dialect and can be used by validators and editors to apply the correct rules automatically.