API, Data & Developer Tools

GraphQL Mock Data Generator

Generate deterministic mock results for a GraphQL operation from your schema SDL and field rules, shaped exactly like the server's response, without running a server.

  • data JSON
  • Validation against the operation
  • Rule report
Runs in your browser

Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics.

GraphQL mocks workspace

1 Schema and operation

Example:

2 Settings

Field rules, variables and operation name

Type.field = JSON value fixes a value; Type.field[] = n sets a list's length.

3 Mock response

Paste a schema and an operation, or load an example, then choose Generate result.

What the GraphQL Mock Data Generator does

This generator produces the JSON a GraphQL server would return for a specific operation - same aliases, same nesting, same __typename values - filled with seeded, type-correct mock data taken from your schema SDL. It also checks the operation against the schema, so a typo in a field name is caught before any server is involved.

Front-end work on a GraphQL API often waits for resolvers that do not exist yet. A mock that follows the operation exactly, rather than dumping every field of every type, lets components, stories and tests use realistic responses today - and the seed keeps them stable between runs.

How to use it

  1. Paste the schema SDL and the operation you want a response for, including any fragments it uses.
  2. Pick a seed, how many items lists should have when the operation gives no first or limit, and whether nullable fields should sometimes be null.
  3. Optionally add field rules - Book.price = 12.99 fixes a value, Book.reviews[] = 1 fixes a list length - plus variables and, for multi-operation documents, the operation name.
  4. Choose Generate result. Read the Validation tab first: errors there mean a real server would reject the operation.
  5. Copy or download the response JSON for your component tests, Storybook stories or a stub server.

Reading the results

The response is shaped by the operation, not the schema: only selected fields appear, under their aliases, in the order selected. For a union or interface one concrete type is chosen with the seed, __typename names it, and only the fragments that apply to that type contribute fields.

Operation checks are GraphQL validation rules run against your SDL: every field must exist on its type, required arguments must be present, objects need a selection set and leaves must not have one, fragments must exist and must not loop, and every variable used must be declared.

Shape check is an independent second pass over the generated JSON: every selected key present, non-null fields never null, list fields always arrays, enum values drawn from their enum. It should always pass; if it does not, please treat the output as suspect.

Worked example: a bookshop listing with fragments and a union

The first example uses a small bookshop schema and the ShelfPage query: books(first: $first) with a BookCard fragment and each book's reviews, plus an aliased topHit: search(...) that returns the union SearchResult of Book or Author.

With seed 3, variables { "first": 2 } and the rule Book.reviews[] = 1, the response has two edges, each book has exactly one review whose rating is between 1 and 5, and IDs read like book_1 and author_2. The genre field only ever holds FICTION, HISTORY, SCIENCE or POETRY, because those are the enum's values.

topHit holds three results because the query passes limit: 3. With this seed all three are authors, so each carries __typename: "Author", a name and the two books asked for by books(first: 2) - and none has a title key, since that field is only selected on the Book branch.

How values are chosen

Built-in scalars follow the field name where it helps: email looks like an address, name like a person, title like a title, url like a URL, and rating, stars or score stay between 1 and 5. ID values count up per type, so references are easy to follow. Common custom scalars - DateTime, Date, Time, URL, Email, UUID, JSON, BigInt, Decimal - get suitable values, and anything else gets a string plus a note suggesting a field rule.

List lengths come from, in order: a Type.field[] = n rule, the operation's first, last, limit or similar argument (literal or variable), and finally the Items per list setting.

Limitations: what the result does not prove

  • It knows types, not meaning. Totals do not match the number of items returned, cursors do not really paginate, and related records are not consistent with each other unless you add rules.
  • Directives such as @include and @skip are not evaluated; conditionally included fields are always present.
  • The SDL reader flattens nested lists, so [[Int]] is mocked as [Int]. Input types, default values and custom directive definitions are read but not used.
  • Errors, partial results and the errors array of a GraphQL response are not simulated - the output is always a successful data object.

Privacy: where your data goes

Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.

Standards and sources

Frequently asked questions

How is this different from a GraphQL mock server?

A mock server answers any query at runtime. This page produces one fixed response for one operation, checked against the schema, which is what you want for a snapshot test, a story or a fixture file. Nothing needs to be installed or kept running.

How are unions and interfaces mocked?

For each value the seed picks one possible concrete type - a union member or a type that implements the interface. __typename is set to it, and inline fragments and fragment spreads are applied only when their type condition matches, as a real server would do.

Can I control the exact values in the mock response?

Yes. A rule such as User.email = "[email protected]" fixes a field wherever that type appears, and any JSON value works, including objects for custom scalars. Rules that never match a selected field are reported, which catches misspelt type or field names.

Why does my operation fail validation when it works on the server?

Usually the pasted SDL is older or smaller than the server's schema, or the operation relies on a type added by extend. Paste the complete, current SDL - for example printed by your server or downloaded from its introspection - and try again.

Will the same seed produce the same data after I change the query?

Values are drawn in the order fields are visited, so adding or reordering fields changes what later fields receive. For fixtures that must not move, pin the downloaded JSON file rather than the seed, or fix important values with rules.

Is my schema sent to a server?

No. The SDL and the operation are parsed in this page and the mock is generated here. Nothing contacts a GraphQL endpoint.

Last reviewed by the A2Z.Tools team against the sources listed above.

Rate this tool

Was this tool useful? Your feedback helps us improve it.

No ratings yet — be the first to rate this tool.
Your rating (required)
0 / 2000

Please do not include passwords, payment details or other sensitive information.

Your feedback is sent privately to the A2Z.Tools team and will not be posted publicly.