How to Generate Realistic Mock JSON Data for Testing and Prototyping
Testing 9 min readUpdated October 12, 2026
Good test data is not random noise. It is data that looks like the real thing, contains the awkward cases that break software, and can be recreated exactly when a test fails. Whether you are building a front end before the backend exists, testing an API, or preparing a demo, this guide covers how to make mock JSON that is actually useful.
Why mock data matters
- Front-end work can start before the API is finished. Agree on the response shape, then build against mock responses.
- Tests stay reliable. Fixed, known data gives repeatable results, unlike a shared database that changes under you.
- Demos and screenshots look professional without exposing customers.
- Load tests need thousands of records that a person would never type.
- Privacy. Copying production data into development is a common source of leaks and compliance problems. Generated data avoids that.
Five principles of useful mock data
1. Match the real structure exactly
Field names, types, nesting and optional fields should follow the real contract. If you have a JSON Schema or an API specification, generate from it, so the mock cannot drift from the real thing. If the real API can return null for a field, your mock data should sometimes do the same.
2. Make values look plausible
A name field containing asdf123 hides layout problems, because real names are longer, shorter and have more kinds of characters. Use realistic names, emails, addresses, prices and dates. A mix of lengths exposes truncation and wrapping bugs early.
3. Keep relationships consistent
If an order refers to customerId: 17, a customer with that id must exist, and order totals should equal the sum of their line items. Generate parents first, then children that reference them.
4. Include the awkward cases on purpose
| Case | Examples to include |
|---|---|
| Empty and missing | [], {}, "", null, an absent optional key |
| Boundaries | 0, 1, the maximum allowed value, one more than the maximum, negative numbers |
| Long and short text | A one-character name, a 200-character name, text with line breaks |
| Special characters | Quotes, backslashes, emoji, accented letters, right-to-left text, <script> tags |
| Dates and times | Leap day, midnight, daylight-saving changes, time zones, far past and future |
| Large numbers | Integers beyond 9,007,199,254,740,991, many decimal places, very large totals |
| Volume | One item, many items, a page boundary (for example exactly 50 records for a page size of 50) |
5. Make it reproducible
Random data is fine until a test fails and you cannot reproduce it. Use a seed, so the same seed always produces the same data, and print the seed when a test runs.
Generate it with code: JavaScript
// npm install @faker-js/faker
import { faker } from "@faker-js/faker";
faker.seed(123); // same seed -> same data every run
function makeUser() {
return {
id: faker.string.uuid(),
name: faker.person.fullName(),
email: faker.internet.email(),
age: faker.number.int({ min: 18, max: 90 }),
plan: faker.helpers.arrayElement(["free", "pro", "enterprise"]),
createdAt: faker.date.past({ years: 2 }).toISOString(),
phone: faker.helpers.maybe(() => faker.phone.number(), { probability: 0.7 }) ?? null,
};
}
const users = Array.from({ length: 25 }, makeUser);
console.log(JSON.stringify(users, null, 2));Generate it with code: Python
# pip install faker
import json
import random
from faker import Faker
Faker.seed(123)
random.seed(123)
fake = Faker()
def make_user():
return {
"id": fake.uuid4(),
"name": fake.name(),
"email": fake.email(),
"age": fake.random_int(min=18, max=90),
"plan": fake.random_element(["free", "pro", "enterprise"]),
"createdAt": fake.date_time_this_year().isoformat(),
"phone": fake.phone_number() if random.random() < 0.7 else None,
}
users = [make_user() for _ in range(25)]
print(json.dumps(users, indent=2, ensure_ascii=False))Related records are easy to build the same way: create the users, then create orders that pick a user id from that list with random.choice, and compute each order total from its items.
Serve mock data as an API
Once you have a JSON file, a front end needs a URL to call. Two common approaches:
- A small mock server such as
json-server, which turns a JSON file into a REST-style API with a single command, good for prototypes and demos. - Request interception with a library such as Mock Service Worker (MSW), which answers requests inside the browser or in tests, so your code calls its real URLs while the responses come from your fixtures.
Generating from a schema
If your data has a JSON Schema, a generator can read it and produce documents that satisfy the types, limits, formats and required fields you defined. This keeps the mock data aligned with the contract. A schema-driven tool does not know the meaning of a field called status, so review the output and add realistic value lists with enum where it matters.
Privacy and ethics
- Do not use real customer data in development, demos or bug reports. Anonymizing it well is much harder than generating fresh data.
- Use obviously fake domains such as
example.comfor emails, and reserved ranges for phone numbers and addresses where possible, so tests can never contact real people. - Keep generated data free of real people's names and personal details when you publish it, for example in documentation or screenshots.
Frequently asked questions
How much mock data do I need?
For interface work, 10 to 50 records are enough to see layout and paging. For performance tests, generate as many as your busiest realistic scenario, and then more. Always include at least one empty list and one maximum-size case.
Is random data a good idea for automated tests?
Only if it is seeded. A failing test must be reproducible, so log the seed and allow it to be set from outside. For tests that must be completely stable, commit fixed fixture files instead.
Should mock responses include errors?
Yes. Add examples of error bodies, timeouts, empty results and responses with missing optional fields, because those are the situations that front ends most often forget to handle.
Can I create mock data without writing code?
Yes. Browser-based generators let you describe fields or paste a schema and download the result as JSON. They are useful for quick prototypes; use code when you need seeds, relationships and large volumes.