How do I validate JSON data with JSON Schema?
First write your JSON Schema rules in the left editor (defining field types, required fields, value ranges, etc.), then input the JSON data to validate in the right editor. The tool automatically performs real-time validation and displays results. Valid data shows a green success prompt; invalid data lists all errors with their JSON Pointer paths. The page loads a user info sample by default, which you can reference when writing your own Schema.
What validation rules does JSON Schema support?
JSON Schema supports rich validation rules: type checking (type), required fields (required), enum values (enum/const), string length and regex matching (minLength/maxLength/pattern), numeric ranges (minimum/maximum/multipleOf), semantic formats (format: email/uri/date-time/uuid/ipv4 etc.), array length and item constraints (minItems/maxItems/uniqueItems/items), object property constraints (properties/additionalProperties/propertyNames), logical combinations (allOf/anyOf/oneOf/not), conditional validation (if/then/else), and reference reuse ($ref/$defs). The 'JSON Schema Keywords Cheat Sheet' below lists all common keywords with examples.
What's the difference between anyOf, oneOf, and allOf?
allOf means data must match all sub-schemas (logical AND, commonly used for schema inheritance/extension); anyOf means data passes if it matches at least one sub-schema (logical OR, allows multiple matches); oneOf means data must match exactly one sub-schema (XOR, precisely one match). For example, use anyOf when a field can be either string or number; use oneOf when auth type must be exactly one of bearer or basic.
Does it support $ref references and shared definitions?
Yes. The tool resolves local references including $ref: '#/$defs/xxx' form definition reuse (Draft 2019-09+ uses $defs, older specs use definitions), and references to other paths within the same file. You can define reusable sub-structures in $defs and reference them in multiple places. Note: External remote references (cross-URL $ref) are not automatically resolved for security reasons.
What's the difference between JSON Schema validation and JSON formatting?
JSON formatting (also called JSON beautify/minify) only changes JSON indentation/layout to make it more readable or compact, without checking content validity. JSON Schema validation checks whether JSON data content matches your defined rules (types, ranges, required fields, etc.) - this is content validation. JSON syntax errors (extra commas, mismatched quotes) are basic errors; Schema validation includes syntax checking but goes far beyond - it also validates business-rule level legitimacy.
Which JSON Schema specification versions are supported?
The tool supports all five major versions: JSON Schema Draft 4, Draft 6, Draft 7, Draft 2019-09, and Draft 2020-12. By default it auto-detects the version from the $schema field in your Schema; you can also manually switch versions in the toolbar for testing. Draft 7 is currently the most widely used version; Draft 2020-12 is the latest stable version. The 'Version Comparison Table' below lists functional differences between versions.
Can error reports locate specific field positions?
Yes. Every validation error provides a standard JSON Pointer path (e.g., /user/address/city or /items/0/name) precisely indicating the failing field location. Clicking an error in the error list auto-scrolls the editor to that location. JSON Pointer uses RFC 6901 standard with slash-separated segments and zero-based array indices.
How do I use JSON Schema required?
required is a string array placed at the object level schema, listing which properties are required. For example: "type": "object", "properties": { "id": {"type": "string"}, "name": {"type": "string"} }, "required": ["id", "name"] means id and name fields must exist. Note: required goes in the parent object level, not inside each property's schema - this is the most common beginner mistake.
How do I write JSON Schema pattern regex?
The pattern keyword is for string types; its value is a regular expression string (following ECMA-262 regex syntax), and the string must match this pattern to pass. For example "pattern": "^[a-zA-Z0-9_]{3,16}$" validates usernames, "pattern": "^1[3-9]\d{9}$" validates Chinese mobile phone numbers. Note: regex patterns don't need surrounding slashes /, just write the pattern content directly; backslashes in JSON need to be double-escaped.
What's the difference between JSON Schema enum and const?
enum accepts an array of values; data must be exactly one value from the array, e.g., "enum": ["admin", "user", "guest"] means role can only be one of these three values. const accepts a single fixed value; data must strictly equal this value, e.g., "const": "bearer" means auth type can only be bearer. If an enum has only one value, use const instead for clearer semantics.
How do I use JSON Schema additionalProperties?
additionalProperties controls whether objects allow extra properties not defined in properties. Set to false to disallow any extra properties (strict mode); set to true to allow any extra properties (default behavior); can also be set to a schema object that extra properties must conform to. For example "additionalProperties": { "type": "string" } means all extra field values must be strings. API development typically recommends false to avoid clients sending unexpected fields.
How do I write JSON Schema if/then/else conditional validation?
if/then/else implements conditional validation: when data matches the if schema, it must also satisfy the then schema; otherwise it must satisfy the else schema (else is optional). Typical scenario: when type field is "business", require businessLicense field; when type is "personal", don't require it. Example: "if": { "properties": { "type": { "const": "business" } }, "required": ["type"] }, "then": { "required": ["businessLicense"] }
What formats does JSON Schema format support?
The format keyword provides semantic format validation. Common values include: date-time (ISO 8601 datetime), date (date YYYY-MM-DD), time (time HH:MM:SS), email (email address), uri (URI/URL), uuid (UUID), ipv4/ipv6 (IP address), hostname (hostname), regex (regular expression), etc. Note: In Draft 2019-09 and later, format defaults to annotation-only without forced validation; this tool enables format validation by default.
How do I validate API responses with JSON Schema?
Write a corresponding JSON Schema based on API documentation (or OpenAPI/Swagger definitions), then paste the actual API response JSON into the data area for validation. Typically you define the top-level response structure (e.g., code/message/data fields), specific structure of array elements in data, and type/constraints for each field. Use $defs to reuse repeated data structures (user info, pagination info, etc.).
How do I interpret JSON Schema errors?
Error messages contain three parts: (1) Path: JSON Pointer to the failing field; (2) Keyword: which validation keyword failed (required, type, minimum, pattern, etc.); (3) Message: specific failure reason. For example, error path /age, keyword minimum, message "must be >= 0" means the age field value is less than 0, violating minimum constraint. Clicking an error jumps directly to the corresponding code location.
What's the difference between JSON Schema and TypeScript types?
TypeScript types only check at compile time, don't exist at runtime, and cannot validate external input data (API request bodies, user input). JSON Schema is runtime data validation that can validate specific value ranges, regex matching, enum values, required fields, array lengths, and other fine-grained constraints that TypeScript cannot express. In practice, both are often combined: TypeScript for static type checking, JSON Schema (or JSON Schema-based validators like Ajv/Zod) for runtime data validation. Tools exist to convert between JSON Schema and TypeScript types.
