Your screen is too small. Please widen your browser window or use a device with a screen width of at least 300px to use this app.
Serve fake JSON data over a real HTTP URL. Paste the exact response body you want, or let AI vary chosen fields on every call so your UI is never tested against the same row twice.
Importing a JSON file into a component gets data on the screen, but it skips everything that makes a network call a network call. There is no loading state, because the data is already there. There is no error branch, because an import cannot fail at runtime. There is no race, no abort, no stale response arriving after the user has navigated away.
Those are precisely the paths that break in production. Serving the same JSON over HTTP costs nothing extra and puts every one of them back in play, and the mock API generator is where you define the endpoint that serves it.
Paste any valid JSON object and the endpoint answers with it, unchanged. This matters more than it sounds: many tools round-trip your JSON through a parser before sending it, which reorders integer-like keys and quietly destroys any number past 2^53. An id like 9007199254740993 has to survive, and here it does.
{
"id": 1,
"name": "John Doe",
"email": "john@example.com",
"orders": [
{ "id": "A-1001", "total": 42.5, "status": "shipped" }
]
}Placeholder data is uniform in a way real data never is. Every name is the same length, every price ends in .00, every list has three items. UIs built against that data look fine until the first real row arrives and a card overflows.
Turn on AI variants, tick the fields that should change, and the endpoint keeps its shape while those values are regenerated on every call. The keys, the nesting, and the fields you did not tick stay exactly as you wrote them.
// first call
{ "id": 1, "name": "Marguerite Ellsworth", "email": "m.ellsworth@northwind.co" }
// second call, same endpoint
{ "id": 1, "name": "Bo Tran", "email": "bo.tran@lumen.io" }Most dummy JSON data you find lying around is a single object or a list of three. That is enough to prove a fetch works, and not enough to find out what your table does at row forty. A body here holds up to 50 items in one list and runs to 30,000 characters, which is a screen of results rather than a sample of one.
Size is also how you reach the states nobody tests. Give one endpoint the full list, a second the same shape with an empty array, and a third a single item, and the empty state and the one-result layout stop being things you find out about after release.
Precise when you want it, varied when you need it.
Key order, spacing, and long numbers survive intact. The response is your own text, not a re-serialized copy of it, so a 19-digit id does not come back rounded.
Nest up to 12 levels deep with up to 50 items in any one list, which covers the shape of most real payloads.
Paste a body, save, and call the URL. No backend, no deploy.
Tick the fields that should change and each call regenerates them, up to 50 fields and 150 values at a time. Everything else stays exactly as written.
Names of different lengths, emails that are not all the same domain, prices that are not all round. Layout bugs show up under varied data, not under placeholder data.
A body can run to 30,000 characters, enough for a full page of results rather than a single token row.
AI variation is off by default. Leave it off and the endpoint answers identically every time, which is what a snapshot test wants.