Paste a JSON Schema and get valid examples plus one invalid case per rule, each named for the rule it breaks and checked by the validator.
To generate test cases from a JSON Schema, paste the schema and the page returns valid examples (minimal, maximal and typical) and one invalid case for each rule it can break, each named after that rule. Worked example: the sample schema asks for an integer id of at least 1, a name of 1 to 10 characters, an email, an optional role, a five-digit zip and 1 to 3 unique tags, with no extra keys. With the defaults it returns 4 valid examples and 20 invalid cases. The minimal example is {"id": 1, "name": "a", "email": "a@b.co"}, the maximal one fills every optional key to its limit, and two typical ones use the seed. The invalid cases include missing required 'id', minimum 1: 0 is below it at /id, and maxLength 10 exceeded by 1 at /name, whose name is 11 characters long.
The page builds a typical valid document with every optional key present, then changes one thing at a time: it deletes a required key, adds an extra key where additionalProperties is false, puts a value of the wrong type, one character past maxLength, one below minimum, one item past maxItems, a duplicate where uniqueItems is set, or a string that fails the pattern or the format. For anyOf and oneOf it looks for a value that matches none of the options, and for oneOf also one that matches more than one. Every case, valid or invalid, is then run through the same checker as the JSON Schema Validator page. A valid case must pass. An invalid case must be rejected, and the checker must name the rule the page meant to break. A case that fails that test is dropped and listed under Not generated, so nothing is presented as good without being confirmed.
The page reads type, enum, const, required, properties, additionalProperties, items, prefixItems, contains, minItems, maxItems, uniqueItems, minLength, maxLength, minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, pattern, format, allOf, anyOf, oneOf, not, if with then and else, dependentRequired, minProperties, maxProperties, and local references such as #/$defs/name. Formats email, date, date-time, uri, uuid and ipv4 are generated and broken on purpose; other format names are listed and plain text is used. Patterns are generated for common shapes such as [A-Z]{2}-[0-9]{4}, groups with alternation, character classes and counts. A pattern with lookahead or a backreference is tried against a short list of common strings, and if none fits, the property is reported as not generated. Draft-07 tuple items become prefixItems and nullable: true allows null, and a notice says so.
Invalid cases are not made for patternProperties, propertyNames, dependentSchemas, unevaluatedProperties, unevaluatedItems, minContains, maxContains or the conditions in if, then and else; valid examples still follow those rules where the checker accepts them. Rules inside a oneOf or anyOf branch are not broken one by one, only the choice between branches. A reference to another file or address is never fetched. A schema that refers to itself is entered once, so a tree gets one level of invalid cases. The output stops at 150 cases and the checker runs at most 400 times in one update. Values are fixture data, not realistic records: strings are made of letters from a short word list, and a maximal string with no maxLength is 24 characters.
Choose JSONL to get one case per line, which most test runners and loaders read directly, or JSON for a single array. The Each case setting switches between records with name, valid flag, rule and path, and plain data. The seed is a whole number from 0 to 999999. The same schema and the same seed give the same cases in any browser, so a fixture file can be regenerated and compared. An agent can open this page with the schema already filled in by adding #input= followed by the URL-encoded schema to the address.
Paste the schema in the box. The page returns a minimal, a maximal and two typical valid examples, then one invalid case per rule it can break. The sample schema gives 4 valid examples and 20 invalid cases, and the table lists each with its rule.
Every case is run through the checker behind the JSON Schema Validator page. An invalid case is kept only if the checker rejects it and reports the rule that was meant to break, such as maxLength. A case that does not pass is listed under Not generated.
The page builds strings from common pattern shapes, such as ^[0-9]{5}$ or ^(ab|cd)-[a-z]+$. A pattern with lookahead like ^(?=a)x or a backreference like (a)\1 cannot be followed, so the page tries a short list of common strings and reports the property as not generated if none matches.
Yes. The seed, a whole number from 0 to 999999, drives every random choice. Seed 1 always gives the same typical examples for the same schema. Change the seed to 2 for different ones. The minimal example does not depend on the seed.
Mostly. Rules are checked with the draft 2020-12 core. Draft-07 tuple items arrays are read as prefixItems, additionalItems as items, and nullable: true as also allowing null. Keywords outside the supported list, such as $dynamicRef, are ignored.
No. The text is processed in your browser and not uploaded. Only the settings you choose, such as the output format and the seed, are saved in this browser, never the schema or the cases.