JSON Schema Validator

Overview

Validates a JSON document against a JSON Schema in two side-by-side editors: paste the data on the left, the schema on the right, and the verdict appears below with a bulleted list of every violation found. The checks cover the root type, required properties, per-property types, and enum membership, computed live as either panel changes.

How It Works

Replace the sample data and schema with your own; both panels accept any valid JSON. The validator reports Missing required property for each key listed in the schema's required array that is absent from the data, type mismatches for properties whose declared type is string, number, or boolean, and enum violations when a value is not among the allowed list. A green banner means the document validates; a red one lists each error explicitly. Malformed JSON in either panel is reported as a parse error with the parser's message.

Step-by-Step Usage Guide

1. Paste the JSON document to validate into the left editor.
2. Paste or edit the schema in the right editor, keeping the required and properties keywords.
3. Read the verdict banner; errors are listed per property with the reason.
4. Fix the data or the schema until the green validation banner appears.

Technical Specifications & Standards

The validator implements a focused subset of the Draft-07 keyword set, and its coverage boundary matters when you migrate from stricter tools. What is enforced: the root object check, the required array, the type keyword for string, number, and boolean property types, and the enum keyword with array membership. What is not: nested object validation beneath the top level, array schemas including items and minItems, string constraints such as minLength, maxLength, pattern, or format, numeric bounds like minimum and maximum, additionalProperties, and the $ref composition that real schemas lean on. A schema using those keywords will validate more permissively here than under Ajv or a language runtime library, so a green result is weaker evidence than the same result from a full validator; conversely, the errors it does report are precise and named by property. Draft lineage is also not detected: the tool does not read the $schema declaration and behaves the same for a Draft-07 or 2020-12 schema, which is mostly harmless for the keywords it supports because their meaning is stable across drafts. For anything beyond the covered subset, validate with a full implementation; use this page for quick checks of flat document shapes and for learning the core keywords.

Targeted Use Cases

• Checking a config file's shape before a deploy, especially which keys are required.
• Learning how type, required, and enum behave in a JSON Schema.
• Quickly confirming that an API payload matches a flat response contract.
• Testing whether an enum value typo is what is failing a downstream validator.

Notes & Gotchas

• Remember the subset: nested objects, arrays, patterns, and numeric bounds are not enforced, so green does not mean fully compliant.
• Keep schemas flat here; for deep structures use a complete validator such as Ajv with the same schema.
• Fix parse errors first; a malformed schema or document stops all validation with a parse message.
• List every mandatory key in required explicitly, because absence is only detected for keys named there.

Frequently Asked Questions