JSON Schema Sample Generator
Generate example JSON data from a JSON Schema — for API docs, mock responses and test fixtures. Seeded, so the same schema and seed always produce identical output. Runs entirely in your browser.
Input
More than one wraps the results in an array (or one per line, for NDJSON).
The same schema, seed and settings always produce the same data. Change it to reroll.
Stops recursive schemas ($ref pointing at themselves) from nesting forever.
Output
Guides
Turn a JSON Schema into example data you can actually use — API documentation payloads, mock responses, frontend placeholders and test fixtures. Paste the schema, get valid JSON back. Nothing is uploaded; the generator runs in your browser.
The output is seeded, which is the part most sample generators skip: the same schema, seed and settings always produce byte-identical data. That means you can commit the result as a fixture and regenerate it later without a noisy diff — and change the seed when you want a different set.
How to use it
- Paste your JSON Schema into the input box.
- Drag Samples up if you want more than one record — 2 or more are wrapped in an array (or written one per line in NDJSON mode).
- Pick an output format: pretty JSON, minified JSON, or NDJSON for seeding a database or a log pipeline.
- Set Optional properties to control how closely the sample hugs the required set.
- Copy or download the result.
Settings
- Seed — any text. Same seed in, same data out. Change it to reroll.
- Optional properties — Include all fills in every declared property; Required only emits just the keys listed in
required(a good check that your consumers handle a minimal payload); Randomly include varies them per sample, which is closer to real-world traffic. - Max depth — how far to recurse before bottoming out with an empty object/array. A schema whose
$defsentry references itself (a tree node, a comment thread) would otherwise nest forever.
What the generator understands
type (including type arrays), properties, required, items — both the single-schema and tuple forms — enum, const, default, examples, oneOf, anyOf, allOf, and local $ref pointers into $defs or definitions. Numeric constraints (minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf), string constraints (minLength, maxLength) and array constraints (minItems, maxItems, uniqueItems) are all honoured.
Fixed values take priority in this order: const, then default, then examples, then a pick from enum. So a schema that pins "type": {"const": "user"} always gets "user", never a random word.
Why do the values look realistic instead of "string1"?
Two signals. format comes first — email, uri, uuid, date, date-time, time, duration, hostname, ipv4, ipv6 and json-pointer each produce a properly shaped value. When there's no format, the property name is used: a field called email, createdAt, city, phone, price or id gets something plausible for that name. It makes generated API docs far easier to read.
Does it handle pattern?
No — synthesising a string from an arbitrary regex is a different problem, and a wrong guess is worse than an obvious placeholder. A string with only a pattern falls back to a word from the pool. Add a format, an enum, or a default if you need the value to match exactly.
Which JSON Schema draft does it support?
The keywords above are shared across Draft-07, 2019-09 and 2020-12, so schemas from any of those work. $defs and the older definitions are both resolved. Remote $ref URLs are not fetched — inline them first, since nothing here touches the network.
Related tools
Going the other way — inferring a schema from data you already have — is JSON Schema Generator. To check that a payload really satisfies a schema, use JSON Schema Validator. If you want mock records without writing a schema at all, Fake Data Generator takes a simple field list instead.