b2KIT

JSON Schema Validator

Validate JSON data against JSON Schema definitions with detailed error reporting and schema generation.

Tested tool guide Tested browser tools Checked August 16, 2026

What JSON Schema Validator does and how it behaves

JSON Schema Validator compares a JSON instance with a separate JSON Schema and reports where the instance violates declared constraints such as types, required properties, numeric ranges, string patterns, or array rules. It can also generate a starting schema from sample JSON. The common surprise is that valid JSON is not necessarily schema-valid JSON: successful parsing only confirms the text follows JSON syntax. Also, listing a name under `properties` does not make that property mandatory; the schema must include it in `required`.

How the result is produced

1

Validate an instance

Supply the JSON document to test and the schema that describes its permitted shape. The validator parses both documents, evaluates applicable schema keywords, and reports failed constraints with their associated locations. A successful result means that particular instance satisfies that schema. It does not establish that the instance meets requirements that the schema never expressed.

2

Generate a starting schema

Schema generation derives a candidate definition from the structure and value types present in sample JSON. Review the result before treating it as a contract. One sample cannot reveal every permitted alternative, optional property, range, pattern, or conditional relationship. Generated constraints may therefore be narrower or less complete than the intended data model.

Good uses

  • Check an API request or response example against the schema published for that endpoint, then use the reported instance location and failed keyword to find the mismatched field.
  • Test fixture files after changing a schema, especially when adding required properties, restricting enumerated values, changing array item rules, or tightening numeric and string constraints.
  • Create an initial schema from a representative JSON document, then edit it into an explicit contract for configuration files, event payloads, stored records, or exchanged messages.

Limits and checks

  • A validation failure can begin as a JSON parsing failure. Comments, trailing commas, single-quoted strings, `undefined`, and unquoted property names are not valid JSON, so schema evaluation cannot meaningfully proceed until the text parses.
  • Schema behavior can depend on its declared dialect. Inspect the `$schema` URI and avoid assuming that keywords introduced, removed, or revised in another JSON Schema draft will have the same meaning.
  • Passing validation proves only conformance to the supplied schema. It does not verify business facts, cross-document consistency, database existence, authorization, or any rule that the schema does not encode.

Common questions

Why is a property accepted even though it appears in `properties`?

The `properties` keyword supplies subschemas for properties when they occur; it does not require those names to occur. Add the property name to the containing object's `required` array when omission should fail validation. Conversely, `required` does not by itself define the property's allowed type or value, so the two keywords commonly appear together.

Can I use a generated schema as a finished specification?

Usually no. Generation can describe observations from the supplied sample, but it cannot infer unstated intent. Review optional versus required fields, additional properties, nullability, arrays, formats, ranges, alternatives, and reusable definitions. Validate several deliberately valid and invalid examples before publishing the result as a contract.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools