JSON Schema Validator

How to Use the JSON Schema Validator

The validator has two panels side by side. The left panel is for your JSON Schema — the blueprint that describes the expected structure and constraints of your data. The right panel is for the JSON data you want to validate against that schema. Once both panels have content, click the Validate button to run the check.

If validation passes, a green success indicator appears. If it fails, you will see a list of detailed error messages. Each error includes the data path (for example, /user/email) pointing to the exact location in the JSON where the violation occurred, the schema path showing which part of your schema triggered the error, and a human-readable description of the problem — such as "must be string" or "must have required property 'id'".

Click Load Sample to populate both panels with a working schema and data example. This is a useful starting point if you are new to JSON Schema — you can study the relationship between the schema keywords and the data they constrain, then modify both panels to match your own use case.

The validator uses Ajv (Another JSON Validator), the most widely adopted JSON Schema validation library in the JavaScript ecosystem. All processing happens in your browser — your schemas and data never leave your machine. If you need to validate raw JSON structure before applying a schema, the JSON Validator and JSON Formatter are useful companion tools.

What is JSON Schema?

JSON Schema is a vocabulary — published as an IETF draft standard — that lets you describe the structure, types, and constraints of a JSON document in JSON itself. Think of it as a type system for your API payloads, configuration files, and database records. A schema is a JSON object containing keywords that express rules: which fields are required, what data types are expected, what string patterns are valid, and what numeric ranges are acceptable.

The most widely deployed version is Draft-07, which introduced if/then/else conditional validation and readOnly / writeOnly annotations. The newer Draft 2020-12 overhauled how $ref and dynamic references work and clarified several ambiguities. Both drafts share the same core keyword set, so schemas written for Draft-07 are largely compatible with 2020-12 validators.

JSON Schema integrates with code generation tools (OpenAPI generators, form libraries like React JSON Schema Form), IDE plugins (VS Code schema validation for package.json, tsconfig.json), and API gateway validation middleware. Writing a schema once gives you validation at every layer of your stack without duplicating constraint logic in application code.

Common Use Cases

• API contract validation — Define the expected shape of request and response bodies in an OpenAPI spec (which embeds JSON Schema). Validate incoming payloads at the API gateway before they reach your service, returning structured errors to clients automatically.
• Configuration file validation — Ship a schema alongside your application's config file so that CI pipelines and editor plugins can warn users immediately when a required field is missing or a value is out of range. VS Code reads $schema pointers in JSON files and provides inline validation and autocompletion.
• Dynamic form generation — Libraries like React JSON Schema Form and jsonforms.io render full UI forms directly from a JSON Schema, including field types, labels, and validation rules. Maintaining one schema eliminates the need to keep UI constraints in sync with backend validation logic.
• Data pipeline validation — Validate each record in a CSV-to-JSON or ETL pipeline before writing to a database or forwarding to a downstream service. Rejecting malformed records early prevents corrupt data from propagating through the pipeline.
• Contract testing — Use schemas as contracts between microservices. When a producer service changes its response shape, a schema compliance test in the consumer's test suite catches the breaking change before deployment.

Best Practices and Tips

Start every schema with the required array. It is easy to forget that JSON Schema treats all properties as optional by default — a schema with a properties block but no required array will accept an empty object without complaint. List every field your application genuinely cannot function without.

Use $ref and $defs (or definitions in Draft-07) to define reusable sub-schemas. If three different objects in your API all have an address field with the same structure, define Address once under $defs and reference it with {"$ref": "#/$defs/Address"}. This keeps schemas DRY and makes maintenance far easier as your data model evolves.

Keep schemas versioned alongside your API. When you add a required field, that is a breaking change — it will fail validation for consumers sending the old payload shape. Use your schema version history as a changelog for your API contract.

Validate at API boundaries, not only in client code. Client-side validation is a UX feature; server-side schema validation is a correctness guarantee. Use Ajv or a similar library as middleware so that malformed requests are rejected with structured error responses before reaching business logic.

Use additionalProperties: false in strict schemas to reject objects with unexpected keys. This prevents clients from sending extra fields that might be misinterpreted by future versions of your API, and helps catch typos in field names during development.

Common Schema Keywords

• type — Specifies the data type: string, number, integer, object, array, boolean, or null
• properties — Defines the expected properties of an object and the sub-schema each must satisfy
• required — Lists property names that must be present in the object
• enum — Restricts a value to a fixed set of allowed options
• pattern — Validates a string against a regular expression (e.g., email format, UUID format)
• minimum / maximum — Sets inclusive numeric bounds; use exclusiveMinimum / exclusiveMaximum for exclusive bounds
• minLength / maxLength — Constrains the length of a string
• items — Describes the schema that every element in an array must satisfy
• additionalProperties — Controls whether properties not listed in properties are allowed
• if / then / else — Applies conditional validation depending on whether the if schema validates

Related Tools and Guides

• JSON Validator — Validate raw JSON syntax before applying a schema
• JSON Formatter — Format and prettify JSON data for easier reading
• JSON Schema Tutorial: Validate Your Data — learn schema keywords, types, and real-world examples

FAQ

What JSON Schema drafts are supported?

The validator uses Ajv which supports Draft-07 by default, the most widely used JSON Schema specification. Draft-07 introduced if/then/else conditional validation and is the version embedded in OpenAPI 3.0.

Is my data safe?

Yes. All validation happens in your browser using the Ajv library compiled to JavaScript. No schema or data is sent to any server.

What happens if my JSON is invalid?

You will see detailed error messages showing the exact data path, the validation keyword that failed, and a human-readable description of the issue — for example, "must be string" or "must have required property 'id'".

Can I use $ref in my schema?

Local $ref references within the same schema document are fully supported — use $defs or definitions to define reusable sub-schemas. External $ref URLs pointing to remote schemas are not fetched for security reasons.

Can I validate arrays of objects?

Yes. Use the items keyword to specify the schema each array element must conform to. Combine it with minItems and maxItems to enforce length constraints, or with uniqueItems: true to disallow duplicate values.

How do I mark a field as required?

Add the field name to the required array at the same object level as your properties keyword. For example: "required": ["id", "name"]. Any property not listed in required is optional by default — JSON Schema does not make assumptions about which fields are mandatory.