Mock JSON data is generated data that looks real but isn't. Test suites, prototypes and demos all need it. Typing a few user objects by hand works until you need fifty, each with a valid UUID, a believable email and a date that doesn't look copy-pasted. A mock JSON data generator creates records with the same shape as production data, so you can build and test against something realistic.
This guide covers generating mock JSON from a field spec, using a browser generator and the Faker libraries in JavaScript and Python, and how they compare with JSON Schema Faker. It ends with the practices that keep fake data useful and safe: fixed seeds, realistic distributions and no real PII.
Why you need mock JSON data
You can't test a feature that displays users until you have users, and you don't want a unit test to depend on a production database. Fake but realistic records let you work in isolation, at any scale, without waiting on anyone.
Common uses for mock JSON:
- Automated tests. Fixtures for unit and integration tests that need dozens of records with valid-looking fields, not three hand-written stubs.
- Frontend prototypes. Build a UI against a realistic JSON payload before the backend API exists.
- Database seeding. Fill a dev or staging database so the app has data during local development.
- Demos and screenshots. Fill dashboards and tables with believable names and numbers instead of "test test test".
- Load and edge-case testing. Generate thousands of rows, or deliberately odd ones, to stress a parser or endpoint.
The goal is the same each time. You want data with the right shape and enough realism to exercise your code, generated quickly enough that regenerating it is cheaper than maintaining it by hand.
Generate mock JSON from a field spec
The simplest way to generate mock JSON is to describe the record as a field spec, a map of field names to types. The generator then produces as many records as you ask for. You say what each field is (a UUID, an email, a past date), not how to compute it.
The spec is JSON too. It has an optional record count and a fields object that maps each key to a type name.
{
"count": 3,
"fields": {
"id": "uuid",
"name": "fullName",
"email": "email",
"signedUpAt": "date.past",
"age": "number.int",
"active": "boolean"
}
}Give that spec to the generator and it returns a JSON array of records. Each field gets a value of the requested type:
[
{
"id": "9f1c7a2e-4b83-4d1a-a7e0-2c5f9b8d6e11",
"name": "Grace Hopper",
"email": "grace.torvalds@globex.io",
"signedUpAt": "2024-08-14T00:00:00.000Z",
"age": 47,
"active": true
},
{
"id": "c3d8e5f1-7a92-4e6b-b104-8f2a1c9d7e34",
"name": "Linus Liskov",
"email": "linus.hamilton@acme.dev",
"signedUpAt": "2023-11-02T00:00:00.000Z",
"age": 31,
"active": false
}
]The spec is the whole contract. Adding a field, changing the count or swapping a type is a one-line change, and the spec also documents what your records look like. The available types are uuid, fullName, firstName, lastName, email, username, date.past / date.future / date.recent, number.int, number.float, boolean, city, country, company, phone, url, ipv4, color and lorem.word / lorem.sentence.
Generate mock JSON data online
For quick, one-off dummy JSON data you don't need to write code. Paste a field spec, choose how many records you want (up to 10,000), and copy the array into a fixture file or a fetch mock.
The generator runs in your browser. Nothing is uploaded. It is also deterministic: the same spec text gives the same data every time, which is what you want when a test checks specific values. To tidy the output, use the JSON Formatter to pretty-print it or the JSON Minifier to put it on one line. Before you commit a large fixture, run it through the JSON Validator to check that it parses.
Faker libraries in JavaScript and Python
When you need mock data inside a test suite or seed script, with loops, conditionals and relationships between records, use a Faker library. It gives you control a static spec can't: nested objects, foreign keys, weighted choices and locale-aware output.
JavaScript with @faker-js/faker
import { faker } from "@faker-js/faker";
// Fix the seed so every run produces identical data.
faker.seed(42);
function makeUser() {
return {
id: faker.string.uuid(),
name: faker.person.fullName(),
email: faker.internet.email(),
signedUpAt: faker.date.past().toISOString(),
age: faker.number.int({ min: 18, max: 80 }),
active: faker.datatype.boolean(),
};
}
const users = Array.from({ length: 5 }, makeUser);
console.log(JSON.stringify(users, null, 2));Python with Faker
import json
from faker import Faker
fake = Faker()
Faker.seed(42) # deterministic output
def make_user():
return {
"id": str(fake.uuid4()),
"name": fake.name(),
"email": fake.email(),
"signed_up_at": fake.past_datetime().isoformat(),
"age": fake.random_int(min=18, max=80),
"active": fake.boolean(),
}
users = [make_user() for _ in range(5)]
print(json.dumps(users, indent=2))Both libraries have hundreds of providers (addresses, companies, card-shaped numbers, IP addresses, lorem text) and support locales. You can generate German names or Japanese addresses to test internationalization. The Python snippet serializes with the json module. The JavaScript one uses JSON.stringify.
Generate mock data from a JSON Schema
If you already have a JSON Schema for your API, for request validation or documentation, you can generate mock data from it instead of writing a separate spec. The json-schema-faker library reads a schema and produces a matching instance. It respects minimum, maximum, format, enum and required.
import { JSONSchemaFaker } from "json-schema-faker";
const schema = {
type: "object",
required: ["id", "email", "age"],
properties: {
id: { type: "string", format: "uuid" },
email: { type: "string", format: "email" },
age: { type: "integer", minimum: 18, maximum: 80 },
role: { type: "string", enum: ["admin", "user", "guest"] },
},
};
JSONSchemaFaker.option({ alwaysFakeOptionals: true });
const record = JSONSchemaFaker.generate(schema);
console.log(JSON.stringify(record, null, 2));This gives you one source of truth. The schema that validates real requests also generates the mocks, so test data can't drift away from your contract. If you don't have a schema yet, generate a starting point from a sample payload with the JSON Schema Generator, then adjust the constraints by hand. For more on the schema language, see the JSON Schema guide.
Which approach to use
Each method trades control for convenience. Choose based on where the data lives and how much logic it needs.
| Approach | Best for | Control | Setup |
|---|---|---|---|
| Online generator | Quick fixtures, demos, one-off data | Low (fixed type list) | None |
| Faker library (JS/Python) | Test suites, seed scripts, relationships | High (full code) | Install a package |
| JSON Schema Faker | Teams with an existing schema | Medium (driven by schema) | Install + a schema |
- Use an online generator when you want data in ten seconds and it doesn't need to change at runtime.
- Use a Faker library when the data lives in code, such as a test factory, a seed script or records that reference each other.
- Use JSON Schema Faker when you already have a schema and want your mocks to match it.
Best practices for mock data
Use fixed seeds
Random data that changes on every run makes tests flaky and diffs noisy. Seed your generator so the output is reproducible. With a fixed seed, "generate five users" becomes a stable fixture you can assert against. Both Faker libraries take a seed. The online generator seeds itself from the spec text.
Match realistic distributions
Uniformly random data hides bugs that real data would expose. If 95% of your users are active and 5% have churned, generate that ratio with a weighted choice, not a coin flip. Use ages clustered around a believable mean, order totals with a long tail and timestamps mostly in business hours. Realistic shape is what makes mock data catch real problems. Faker libraries have helpers for weighted picks and bounded ranges.
Never use real PII
Keep specs in version control
Commit the field spec or factory code along with your tests. Then anyone can regenerate the same fixtures, review changes to the data shape in a pull request, and see why a test expects a particular value. To keep two versions of a fixture in sync, the JSON Diff tool shows what changed.