How to Generate Sample JSON From a Schema

A JSON Schema is a contract. It says which fields must be present, what types they must have, and which values are allowed. That contract is useful, but it is written in a language of keywords — type, properties, required, minimum, enum — and most people understand a contract faster when they can see an example of something that satisfies it. A sample document does exactly that: it turns the abstract rules into one concrete object you can read, paste into a test, or show a colleague and ask, "Is this what you meant?"

The JSON Schema Sample Generator produces that example for you. You paste in a schema, and it returns a sample JSON document that follows the schema's rules. The point is not to produce production data, and it is not to prove that a schema is correct. The point is to make the schema visible: to reveal what a valid document actually looks like, including the nested objects and arrays that are easy to miss when you only read the schema itself.

How the tool works

A schema is a set of constraints, and a sample generator walks through those constraints and picks a value for each one. For a string field it picks a short sample string; for an integer with a minimum it picks a number at or above that minimum; for an enum it picks one of the listed values; for an array with a minimum length it produces at least that many items. Where a field is listed in required, the sample includes it. Where a field is optional, a good generator still usually includes it, because a sample that hides half the fields is a poor illustration of the shape — but you should remember that its presence in the sample does not make it required. The schema, not the sample, is the authority.

This matters most with nested structures. A flat schema is easy to picture, but a real API schema often has an object inside an object inside an array, with its own required fields at each level. Reading three levels of nesting in schema form means holding several rules in your head at once. A sample flattens that effort: you see the outer object, the inner object, and the array items laid out as ordinary data, and the structure becomes obvious at a glance. The same is true for combinations such as oneOf or anyOf, where the sample shows you one of the permitted shapes rather than leaving you to imagine all of them.

The generator works in your browser, so the schema you paste never needs to leave your device. That is worth noting because schemas sometimes describe internal systems — field names, internal identifiers, business rules — that you would not want to send to a remote service just to get an example. Working locally also means the round trip is fast: change a constraint, regenerate, and see immediately how the sample changes.

A worked example

Take this small schema for a user profile. It requires a name and an age, allows an optional email, and includes a list of tags and a nested address object:

{
  "type": "object",
  "required": ["name", "age"],
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 },
    "email": { "type": "string", "format": "email" },
    "tags": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
    "address": {
      "type": "object",
      "required": ["city"],
      "properties": {
        "city": { "type": "string" },
        "postcode": { "type": "string" }
      }
    }
  }
}

A sample generated from this schema might look like this:

{
  "name": "Alex Morgan",
  "age": 34,
  "email": "alex@example.com",
  "tags": ["reader"],
  "address": {
    "city": "Leeds",
    "postcode": "LS1 4DY"
  }
}

Read it against the schema and every rule checks out: name is a string, age is an integer at or above zero, email follows an email shape, tags has at least one string item, and the address contains its required city. Notice what the sample also reveals at a glance: the address is nested one level down, the tags field is an array rather than a single string, and the email field exists even though it is not required. If you had only read the schema, you might have missed any one of those details. If you are designing an API, this is the moment to ask whether the shape matches your intent — for example, whether tags really should be required to contain at least one item, or whether an empty list should be allowed.

You can also use the sample as test input. Paste it into a request body, a test fixture, or a mock response, and you have a valid starting point without typing a document by hand. From there, you can vary it deliberately: change the age to a negative number to test rejection, remove the name to test a missing required field, or empty the tags array to test the minimum length. The sample is the valid baseline; your variations are the interesting tests.

Common mistakes

The first mistake is treating the sample as the only valid document. A schema usually permits many documents — any string for a name, any non-negative integer for an age — and the generator shows you just one of them. If you copy the sample into documentation as "the" example, readers may assume that the name must be "Alex Morgan" or that the age must be 34. When you share a sample, say that it is one valid example, not the definition.

The second mistake is the reverse: assuming that because a sample was generated, the schema must be correct. A generator follows the rules you wrote, including the ones you wrote by accident. If you meant a field to be required and forgot to list it, the sample may still include it, hiding the error. If you set a minimum of 0 when you meant 18, the sample will happily show an age of 34 and never reveal the mistake. Always read the schema itself, not just its sample, before you publish it.

The third mistake is using sample data as if it were real data. Sample names, emails, and postcodes are placeholders in realistic clothing. They are fine for tests and documentation, but they must never be loaded into a production database, sent to a real user, or used to contact anyone. A sample email address that happens to belong to a real person is a real problem, not a test artefact. Keep sample data in test environments, clearly labelled as such.

A fourth mistake is generating a sample from a schema you have not validated. If the schema itself has a syntax error or a contradictory rule, the sample may be misleading or the generation may fail in a confusing way. Validate first, then generate. The two tools are companions: one checks the rules, the other shows what they mean.

Honest limitations

A sample generator shows one valid instance; it does not check whether your schema is sensible, complete, or the right design for your problem. It cannot tell you that a field is missing, that a constraint is too loose, or that two fields contradict each other in a way the schema language allows but your business rules do not. It also cannot generate realistic data at scale: a handful of samples is useful, but a thousand realistic records with consistent relationships between fields is a different job, and a simple generator will repeat patterns rather than model real distributions. Formats such as email are another boundary: a generator can produce a string shaped like an email address, but that does not mean the address exists or belongs to anyone. Finally, some schema features, such as conditional rules with if and then, may be simplified in a sample; the generated document satisfies the rules as the generator interprets them, and for complex schemas you should still validate the sample against the schema with a dedicated validator.

Closing

A schema is easier to judge when you can see what it permits, and a generated sample gives you that view in seconds. Generate the sample, read it against your intent, use it as a valid baseline for tests, and remember that the schema remains the contract. To check the rules themselves, use the JSON Schema Validator, and to build a schema from existing data rather than writing one by hand, try the JSON Schema Inferrer. For the wider skill of reading and fixing schemas, see How to Infer a JSON Schema From Sample Data.