Skip to main content

Mock JSON Generator

What it does

The Mock JSON Generator produces arrays of fake-but-plausible JSON objects from preset entity types — users, products, posts, orders, addresses — at any count from one to two hundred. Output uses seeded random number generation, which means the same seed always produces the same output; change the seed and the output changes deterministically. Copy directly or download as a .json file.

Common situations

You’re populating a list component during development. The component is built and styled but has no data, which makes it impossible to evaluate at realistic content lengths. Generating ten of the right entity gives you visual substance — long names, edge-case values, varied dates — to test layout and sorting.

You’re seeding a test database with predictable fixtures. Tests that depend on specific records need reproducible data; running the generator with a fixed seed produces the same fifty users every time, on every machine, without committing the JSON to version control.

You’re stubbing API responses for front-end work that runs ahead of the backend. A mock service returns generated JSON that matches the contract; when the real API arrives, you swap the URL and the data shape stays compatible.

You’re producing demo data for a sales presentation or product walkthrough. Real production data isn’t appropriate (privacy, legal, customer concerns); generated fake data looks plausible without exposing anything real.

You’re testing edge cases — what happens with a 200-item list, what happens with users whose names span unusual character ranges, what happens with very large prices. The generator can produce these scenarios on demand without writing them by hand.

What you need to know

The generator uses a linear congruential generator seeded with the user’s chosen number. Each entity type has a small handcrafted set of word lists (first names, last names, companies, cities, countries, categories) and a synthesis function that combines those lists with the seeded RNG to produce plausible records. Names, emails, prices, dates — all derived from the same seed in a fixed sequence.

Same seed, same output. This is the property that makes seeded generators useful for testing. Two developers running the same seed produce identical fixtures. CI runs match local runs. Snapshots stay stable.

Different seeds produce visibly different data but the shape (the JSON structure, field names, types) is constant. This is the constraint: the tool is opinionated about what a “user” or “product” looks like. For bespoke shapes, a more flexible library (Faker.js, Mimesis, factory_bot) is the right tool.

The entity shapes are intentionally generic and broadly useful — id, first_name, last_name, email, created_at for users; id, name, sku, price, category for products. The shapes mirror common database conventions: snake_case fields, id as primary key, ISO 8601 dates.

For larger or more complex datasets, this tool’s 200-record cap is a hard limit. Beyond that, code-based generators are more efficient — Faker.js can produce 100,000 records in a second; this tool would take much longer in the browser.

For realistic statistical distributions (long tails on prices, weighted categories, geographic clustering), the simple uniform random of an LCG won’t match production data. Real production has skews; generated test data is uniformly random. The tool is for development convenience, not load testing or statistical analysis.

Frequently asked questions

What is mock JSON data?

Fake but plausibly-shaped JSON used as test or development data. Has the same structure as real data but contains generated content rather than real users, products, or transactions.

Why use a seed?

Determinism. The same seed always produces the same output. Two developers running the same seed see identical fixtures. CI matches local. Without seeds, every generation produces different data and tests become non-reproducible.

What’s the difference between this and Faker.js?

This tool is browser-based, single-purpose, opinionated about shapes. Faker.js is a code library, configurable, supports custom shapes, runs at any scale. Use this for quick interactive generation; use Faker for build-pipeline test fixtures.

Can I customise the entity shape?

Not in this tool. Five preset shapes (user, product, post, order, address). For custom shapes, write a small Faker.js script — much more flexible.

Will the generated data conflict with real users in my system?

No — the names and emails are entirely fictional. The IDs are random hex strings; the chance of colliding with a production ID using the same scheme is negligible.

Can I generate hierarchical data (orders with line items)?

Not directly. The tool generates one entity type per call. For nested structures, generate each level separately and combine in code.

How realistic is the data?

Plausible at the surface level — names look like names, prices look like prices, dates look like dates. Not statistically realistic — production data has long tails, weighted distributions, and demographic patterns that simple random generation does not produce. Use for development convenience, not for performance or analytics testing.

What’s the largest dataset this can produce?

200 records per generation. For more, generate multiple times with different seeds and concatenate, or use a code-based generator that scales further.

Common problems

Problem: Generated data looks “too random” — every field uses the full word list.

That’s how uniform random works. Real production data has skews — most users have common names, most products are in popular categories, most orders are small. For realistic distributions, use a generator that supports weighted lists (Faker.js with custom config).

Problem: Same seed produces different output across runs.

Should not happen — the LCG is deterministic. If it does, the tool’s RNG implementation may have changed (rare). For absolute determinism, the safe option is to generate once and commit the output, rather than re-generate on each test run.

Problem: The fields don’t match my application’s expected schema.

The tool’s shapes are fixed. For custom schemas, two options: post-process the generated JSON in your test setup (rename, restructure), or use a more flexible generator that lets you define the shape.

Problem: Generated dates are all in the past — I need future dates.

The current generators bias toward recent past dates (last year-ish). Post-process to shift dates forward, or generate a different field type (e.g. expiry dates) that can be future.

Problem: 200-record cap is too small for my use case.

Generate multiple times with different seeds, concatenate the JSON arrays. Or write a small Faker.js script — for hundreds or thousands of records, code-based generation is the right shape.

Quick guides

For Storybook stories: Generate with a fixed seed in the story’s setup, save the JSON as a file in the same folder. Stories import the data; the data stays stable across re-runs.

For Cypress / Playwright tests: Generate fixtures during test setup, use them as API stubs. Same seed = same fixtures = reproducible tests.

For React Native / mobile development: Generate sample data for screens during the design-review phase. Realistic data lengths reveal layout issues real content would otherwise expose only at launch.

Tips

  • Use the same seed across team members for fixtures everyone can see together. Document the seed in your test README.
  • Random seeds (the shuffle button) are useful for “did my code handle the edge cases?” — running with a few different seeds reveals layout assumptions about field length or value range.
  • Output is a JSON array, not a JSON object with a top-level data field. Some APIs wrap their payloads — adjust accordingly when piping the output into tools that expect a wrapper.
  • Two hundred records is the cap. For larger datasets, a CLI tool or a dedicated library is the right shape — generating thousands of records in the browser is wasteful when a Node script does it in a fraction of the time.
  • The data is plausible, not statistically correct. Real production data has long tails, heavy skews, and edge cases that random generators do not produce. Use generated fixtures for development; use real data (or properly anonymised production samples) for performance and load testing.
  • For richer data needs, switch to Faker.js or similar libraries — they support weighted distributions, custom shapes, locale-specific names, and much higher volumes.

Related tools in this suite

The natural pairing is the JSON Formatter — generate fixtures here, format and inspect them there. The UUID Generator is useful when you need IDs that match the format of an existing system rather than the hex strings this tool produces.

Take it further

Test data strategy is a system-level concern. Production-shaped fixtures, seed scripts that run in CI, anonymisation pipelines for sharing real data with developers safely — all of these belong in the build infrastructure, not in ad-hoc generators. The systems we build include those concerns as part of the engineering work; this tool covers the everyday “I need ten fake users right now” case the bigger systems do not need to address.