API Mock Data Generator
Generate realistic fake API responses for development and testing. Use template placeholders, build collections, or generate from JSON Schema.
Last reviewed: April 2026New to this tool? Click here for instructions
Generate realistic fake API response payloads — users, products, orders, addresses, and arbitrary nested entities — directly in your browser, with full control over schema shape, collection size, and output format. Every value is synthetic.
What This Tool Does
The API Mock Data Generator produces realistic-looking JSON payloads that mirror the shape and field types of a real API response — fake users, products, orders, addresses, transactions, blog posts, and any other entity shape you can describe in a template. You give the tool either a JSON template with {{placeholder}} tokens, an object template plus a count for collection generation, or a JSON Schema definition; the tool returns realistic synthetic values: names that read like real names, RFC-shaped email addresses, ISO 8601 dates, UUIDs, phone numbers, company names, city and country pairs, and bounded random integers. Nothing the tool generates is real data and nothing you paste leaves your browser.
The three modes (REST Endpoint, Collection, Schema-Based) cover the most common shapes of "I need fake data shaped like X." REST Endpoint mode wraps the generated body in an HTTP-method and status-code envelope suitable for mock servers like MSW or Postman. Collection mode emits arrays of N objects in plain JSON, JSON Lines, or a wrapped { data: […], total, page, perPage } shape for paginated endpoints. Schema-Based mode accepts a JSON Schema (with type, format, minimum, maxItems, properties, items) and walks the schema recursively to produce a conformant instance. All three modes share the same underlying faker engine and the same token vocabulary. 🔒
How to Use It
Pick a mode using the chips at the top of the tool. The default is REST Endpoint mode, which suits the "I just need one realistic response body" workflow. Collection mode is the right pick when you need a list — fixture data for a table, seed data for a database, or a payload for a paginated endpoint. Schema-Based mode is best when you already have a JSON Schema (from an OpenAPI spec, a JSON Schema validator, or a code generator) and want a conformant example without writing a template by hand.
In REST Endpoint mode, type or paste your JSON template into the left pane. Use {{name}}, {{email}}, {{uuid}}, {{date}}, {{number(min,max)}}, or any of the eighteen token types listed below the textarea. Set the HTTP method and status code from the dropdowns above the textarea. Click Generate to produce one response body; click Copy to put it on the clipboard, or Download to save as mock-response.json. The status bar at the bottom of the tool reports the rendered method, path, status, and payload byte size after each generation.
In Collection mode, paste a single object template and choose a count between 1 and 1000. Pick an output format: JSON Array (a single bracketed list), JSON Lines (one object per line — ideal for bulk database imports), or Wrapped (the standard { data: [...], total, page, perPage } shape returned by most REST endpoints with pagination). Click Generate to render the full collection, then copy or download.
In Schema-Based mode, paste a JSON Schema and choose how many examples you want. The schema walker honors type (string, integer, number, boolean, array, object, null), format hints (email, uuid, date, date-time, uri), numeric bounds (minimum, maximum), array bounds (minItems, maxItems), enum values, and nested properties/items. Click Try Example in any mode to pre-load a sensible sample.
Worked Example: 100 Mock User Objects
The fastest way to learn the Collection mode interface is to generate a non-trivial dataset and inspect the output. The example below renders 100 User objects with realistic-looking fields suitable for prefilling a user-management table during frontend development.
- Template
{ "id": "{{uuid}}", "email": "{{email}}", "firstName": "{{firstName}}", "lastName": "{{lastName}}", "address": { "city": "{{city}}", "country": "{{country}}" }, "phone": "{{phone}}" }- Count
- 100 — a typical fixture size for a paginated table or a Storybook story with realistic scroll behavior
- Format
- Wrapped
{ data: [...], total, page, perPage }— matches the response shape of most paginated REST endpoints
- Switch to Collection mode. Click the Collection chip at the top of the tool. The mode switcher reveals the Count and Format controls.
- Paste the template. Drop the template above (or click Try Example and edit it) into the left pane. Each field name maps to a token:
{{uuid}}renders a v4 UUID,{{firstName}}picks from a curated list,{{city}}/{{country}}render geographically plausible values (Tokyo paired with Japan, Berlin with Germany). - Set count to 100. Tweak the Count input. The tool caps Collection mode at 1000 to keep browser response time low and JSON.stringify reasonable.
- Pick the wrapped format. Choose Wrapped {data: []} from the format dropdown. This produces a top-level object with
data(the array),total(100),page(1), andperPage(100) — the same shape returned by most paginated REST endpoints in the wild. - Generate and inspect. Click Generate. The right pane fills with the rendered JSON; the status bar reports "Generated 100 mock objects" alongside the formatted byte size (typically 22–28 KB for this shape).
- Export. Click Copy to grab the full JSON for paste into a Storybook story, MSW handler, or test fixture; click Download to save as
mock-collection.json.
Expected output: a wrapped envelope with a 100-element array of user objects, each with realistic synthetic values across all seven fields. No two UUIDs collide. Names, emails, and phone numbers look plausible but reference no real person.
{{token}} in the template is replaced by the mock engine with a realistic synthetic value of the appropriate type. In Collection mode the entire expand step repeats for every requested row, producing the full output array.Common Use Cases
Frontend Development Before Backend Is Ready
The flagship use case. A frontend engineer working from an OpenAPI spec needs realistic-looking response bodies to render the UI before the backend team has finished implementing the endpoints. Generating a mock matching the spec — and wiring it into Mock Service Worker (MSW), Cypress intercepts, or a Postman mock server — unblocks UI work entirely. Teams that adopt this pattern routinely cite 30 to 50 percent reductions in cross-team blocking time because UI iteration no longer waits on backend availability.
Storybook Fixture Data
Storybook stories need realistic data to demonstrate component states — empty, single-item, multi-item, error, loading. Hardcoding twenty user objects inline in a story file is tedious and produces stories that all show the same names. Generating a fixture once with this tool, saving it to mocks/users.json, and importing it into the story file produces visually diverse, realistic snapshots without inline clutter. Update the fixture by regenerating and committing — version control captures the diff.
Integration Test Seeding
Integration tests that exercise list pages, search filters, or pagination logic need at least dozens — sometimes hundreds — of records in the test database. Generating a JSON Lines collection from this tool and piping it into a database seeder script (psql \copy for Postgres, mongoimport for MongoDB) populates the test fixture in seconds. The Collection mode JSON Lines output is purpose-built for this — one record per line, no surrounding array brackets, ready for streaming inserts.
Demo Data for Screenshots and Marketing
Product screenshots for the marketing site, App Store listings, and onboarding documentation should never use real user data — both for privacy reasons and because real data is rarely visually clean. Generating synthetic users, projects, and activity histories produces clean screenshots in minutes with no manual redaction step required. Twitter Card and OG preview workflows in particular benefit from synthetic placeholder data that visually reads as "real" without exposing anything.
Load Test Payload Generation
k6 and Artillery load-test scripts often need a corpus of unique-looking payloads to avoid cache-hit confounders during performance measurement. Generate 10,000 mock signup payloads, save as JSON Lines, and have the load-test virtual users round-robin through the file rather than hitting the API with identical bodies. The signed-CDN-byte-size delta between cached and uncached responses is dramatically more visible with varied payloads.
Edge Cases and Limitations
Several constraints and parsing behaviors are worth knowing before you run into them mid-session.
Locale-aware fake data is approximate. The {{phone}} token produces a US-formatted phone number (+1 (XXX) XXX-XXXX) regardless of the {{country}} value in the same template. A UK address paired with a US phone number is a giveaway in screenshots. For locale-correct mocks, generate per-locale collections separately, or post-process the output with a locale-aware library like @faker-js/faker (which honors faker.setLocale('en_GB')).
Reproducibility requires explicit seeding. The browser tool uses Math.random(), which is not seedable in standard JavaScript. Outputs vary between clicks — useful for diversity, fatal for snapshot tests. For reproducible fixtures, generate once, commit the JSON to source control, and have tests load the committed file. For runtime-reproducible mocks inside a test, switch to a Node script with faker.seed(1234) at the top.
Foreign-key consistency is not automatic. Each {{uuid}} in a template renders an independent fresh UUID. If you generate 100 Users and then 100 Orders each with "user_id": "{{uuid}}", every order's user_id will refer to a user that does not exist. Cross-entity referential integrity has to be enforced after generation — generate the parent collection, capture its IDs, and post-process the child collection to draw user_id values from that ID array. The tool intentionally does not try to express this constraint in a template syntax; it would require a join-aware DSL that would defeat the tool's simplicity.
Date ranges are not entity-aware. {{date}} generates a date within the last two years, independently per token. For an Order, the orderDate should never be earlier than the user's signupDate — but each token call is unaware of sibling values. Post-process to enforce ordering, or generate dates with explicit bounds in Schema-Based mode where "format": "date" can be combined with custom constraints in your post-processing step.
Realistic distributions are not the default. {{number(0,5)}} produces a uniformly random integer between 0 and 5. Real-world entity counts (orders per user, comments per post, sessions per visitor) follow long-tail or power-law distributions where most users have zero or one and a small minority drives most volume. Uniform-random mock data passes type checks but distorts performance characteristics — the hot paths in production are almost always shaped by the long tail. For load-test realism, post-process with a Poisson or geometric sampler.
Behind the Scenes: faker, the 2022 Sabotage, and the Fork
Origins: faker.js and Marak Squires
The faker.js package was first published to npm by Marak Squires in 2010, ported from Ruby's faker gem (itself a port of Perl's Data::Faker). By 2020 it had become a near-universal dependency for JavaScript test suites, Storybook fixtures, and seed scripts — millions of weekly downloads, hundreds of transitive dependents. The library's API surface was broad: faker.name.firstName(), faker.internet.email(), faker.address.city(), faker.commerce.price(), faker.lorem.paragraph(), and dozens more. Most generation approaches were template-based: curated lists of first names, last names, street suffixes, company prefixes, plus a small grammar for combining them into realistic-feeling outputs.
The January 2022 Sabotage Incident
On January 4, 2022, Squires pushed a new version of both colors.js and faker.js that deliberately broke downstream builds — colors.js entered an infinite loop printing "Liberty Liberty Liberty," and faker.js threw immediately on require with a similarly themed message. The motivation, as Squires stated publicly, was protest against unpaid maintenance of widely depended-upon open-source libraries by Fortune-500-scale corporate consumers. The incident broke thousands of CI pipelines worldwide and became a touchstone case in supply-chain security discussions. Squires's npm and GitHub accounts were suspended within 24 hours. The lesson is now standard: pin transitive dependency versions, do not blindly install latest, and audit the maintainer footprint of any small package that ends up in your critical path.
The Fork: @faker-js/faker
The community responded by forking the project under the npm scope @faker-js/faker. The fork is governed by a volunteer team, ships under MIT license, and remains API-compatible for the most common categories (name, address, internet, finance, date, lorem, company). Migration from the deprecated faker package is largely a single import-path change. The fork added explicit seeding support via faker.seed(value), locale-aware data generators (en_GB, de, ja, es_MX, dozens more), and a stricter TypeScript surface. As of 2026, @faker-js/faker is the canonical reference implementation for template-based fake-data generation in the JavaScript ecosystem.
Generation Strategies: Template-Based vs ML-Based
Two broad approaches exist for producing realistic synthetic data. Template-based generation, the model used by faker and by this tool, draws values from curated lists and combines them with simple grammar rules. The advantage is determinism, speed, and zero training cost; the disadvantage is that outputs can feel slightly canned at high volume — the same hundred first names cycle through. ML-based generation trains a model on real distribution shapes and synthesizes data that statistically matches without containing any source record verbatim — useful for high-fidelity load testing and for synthetic data that must pass distribution-shape audits. Libraries like Synthea (medical records), SDV (synthetic data vault), and Mostly AI cover the ML-based end. For the day-to-day "I need a hundred users for my Storybook story" workflow, template-based generation is the right tradeoff.
Comparison: This Tool vs Mockaroo vs JSON Generator vs faker-js
Several mature options exist for synthetic-data generation. They differ along a small number of axes: where generation runs (browser, server, CLI), how many primitive field types are supported, whether dependent fields are expressible, whether scheduled mock API endpoints are exposed, and price. The table below summarizes the trade-offs.
| Tool | Where It Runs | Primitive Field Types | Dependent Fields | Best Use Case |
|---|---|---|---|---|
| This tool | Browser (100% client-side) | ~18 token types (name, email, uuid, date, phone, etc.) | No — each token is independent | Ad-hoc REST response shaping, Storybook fixtures, Cypress mocks |
| Mockaroo | SaaS (their servers) | 200+ field types including industry-specific (medical, finance, ISO codes) | Yes — formula fields (e.g., total = quantity × price) |
Team-scale relational seed data; scheduled mock API endpoints |
| JSON Generator | Browser | ~25 functions via a custom template DSL with loops and refs | Partial — refs within a single template | One-off generation with light cross-field dependencies |
| @faker-js/faker | Node CLI or in-test library | ~80 categories across name, address, internet, finance, commerce, date, vehicle, more | Yes — full programmatic control in user code | Reproducible test fixtures (seeded), runtime mocks inside tests, Node seed scripts |
The practical pattern most teams converge on: use this tool (or JSON Generator) for fast one-off response shaping in the browser, drop in @faker-js/faker as a test-time dependency for runtime-reproducible fixtures, and reach for Mockaroo only when team-shared mock endpoints or 200+ specialized field types are genuinely required. The price gradient runs from free (this tool, faker-js, JSON Generator) through Mockaroo's freemium tier to its enterprise plans for high-volume CSV/SQL exports.
Frequently Asked Questions
Why use mock data instead of a real backend during development?
Mock data lets the frontend ship before the backend is ready, removes network latency from the inner-loop iteration cycle, eliminates rate-limit and quota concerns during heavy debugging, and keeps personally identifiable data out of dev environments entirely. Teams that adopt frontend-first workflows commonly cite a 30 to 50 percent reduction in cross-team blocking time because UI work no longer waits on API contract finalization. Mock data is also reproducible in a way live data is not: a seeded generator returns the same payload every run, which is essential for snapshot tests and visual-regression fixtures.
Is faker.js still maintained?
The original faker.js package authored by Marak Squires is no longer maintained — Squires deliberately broke the package on January 4, 2022 in what became known as the colors.js / faker.js sabotage incident, pushing a version that printed "Liberty Liberty Liberty" in an infinite loop. The community responded by forking the project under the npm scope @faker-js/faker, which is actively maintained by a team of volunteers and serves as the canonical successor. Any new project should install @faker-js/faker rather than the deprecated faker package. The two share API surface for the most-used categories (name, address, internet, finance, date) so migration is mostly a single import-path change.
How do I ensure foreign key consistency across generated entities?
Generate the parent collection first and retain the array of generated IDs in memory. When generating child entities that reference the parent, randomly select an ID from that array rather than minting a fresh UUID. For an Orders collection that references Users, first generate 100 Users and capture their user_id values, then for each Order pick its user_id from that user array. This guarantees every order references a user that actually exists. The same pattern extends to deeper hierarchies — generate Users, then their Addresses (each pointing to a user_id), then Orders (pointing to user_id and shipping_address_id from that user's addresses). The relational integrity step has to be explicit; placeholder tokens alone cannot express cross-row constraints.
Can mock data follow realistic statistical distributions?
Uniform-random generation is the default for template tokens, but production-shaped data rarely follows a uniform distribution. Real-world entity counts tend to follow long-tail or power-law distributions: most users have zero to two orders, a small minority drives the bulk of total volume. To reproduce that shape, sample an order count per user from a Poisson or geometric distribution rather than a uniform range. The same principle applies to dates clustered near recent timestamps, prices that follow log-normal patterns, and country fields weighted by traffic source. Uniform-random mock data passes type checks but fails the load tests it was generated to support — performance bottlenecks usually live in the long tail.
How do I make mock data reproducible across test runs?
Reproducibility requires a seeded pseudo-random number generator rather than Math.random(), which is implementation-defined and not seedable in standard JavaScript. Libraries like @faker-js/faker expose a faker.seed(value) method that initializes their internal PRNG to a known state, so subsequent calls return the same sequence every run. In test suites, seed once at the beginning of each test (or test file) so failures are reproducible from the exact same fixture data. The browser-based generator on this page is not seeded — its outputs vary between clicks — so for snapshot or visual-regression workflows generate the fixture once, commit it to the repository, and have tests load that committed JSON file rather than regenerating on every run.
What about PII in mock data?
Never use real personally identifiable information as mock data, even temporarily. Production user lists, customer emails, real phone numbers, and actual credit card values must never leave the production environment, even into supposedly internal dev or staging databases. Faker-style generators exist precisely to avoid this risk — every name, email, phone, address, and identifier produced by the tool on this page is synthetic. GDPR Article 4 defines personal data broadly enough that a sample CSV of real customer emails copied to a developer's laptop is a reportable incident if breached. The compliance and audit cost of treating real data as mock data is far higher than the engineering cost of generating synthetic equivalents.
Can I use this tool for load testing?
The browser-based generator scales comfortably to a few thousand objects per generation pass, which covers fixture creation for most integration and snapshot tests. For load-testing payloads at tens or hundreds of thousands of rows, the JSON.stringify pipeline in a single browser tab becomes the bottleneck — generate in chunks, write each chunk to a file, then concatenate, or move the generation to a Node.js script using @faker-js/faker which streams directly to disk. For sustained load tests, k6 and Artillery can call into faker inside their VU scripts so each virtual user produces unique-looking traffic without pre-generating a static dataset. Mockaroo's enterprise tier also exports up to one million rows per file if you need a single large CSV without writing code.
Mockaroo or this tool — which should I use?
Use this tool when you need fast, ad-hoc mock data inside a browser tab — generating a sample REST response, prefilling a Storybook story, or building a Cypress fixture without leaving your workflow. Use Mockaroo when you need 200+ field-type primitives, formula-based dependent fields (compute total = quantity × price per row), batch CSV/SQL/Excel export for relational seed data across multiple linked tables, or scheduled mock API endpoints that other team members hit directly. The two are complementary: this tool covers the ~80% case of one-off response shaping at zero cost, and Mockaroo's paid tiers cover the long-tail integration and team-scale needs. Both produce synthetic-only data — no overlap with real-PII territory in either.