How to Generate Mock JSON Data for Testing

Why You Need Mock JSON Data

Mock data solves a chicken-and-egg problem: 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 populated production database. Generating fake-but-realistic records lets you work in isolation, at any scale, without waiting on anyone.

The common scenarios where mock JSON earns its keep:

• Automated tests — fixtures for unit and integration tests that need dozens of records with valid-looking fields, not three hand-written stubs.
• Frontend prototypes — wire up a UI against a realistic JSON payload before the backend API exists.
• Database seeding — populate a dev or staging database so the app looks alive during local development.
• Demos and screenshots — fill dashboards and tables with plausible names and numbers instead of "test test test".
• Load and edge-case testing — generate thousands of rows, or deliberately weird ones, to stress a parser or endpoint.

In every case the goal is the same: data with the right shape and enough realism to exercise your code, produced fast enough that regenerating it is cheaper than maintaining it by hand.

Field-Spec Driven Generation

The most direct way to generate mock JSON is to describe the record you want as a field spec — a map of field names to types — and let the generator produce 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.

A spec is itself just JSON: an optional record count and a fields object mapping each key to a type name.

{
  "count": 3,
  "fields": {
    "id": "uuid",
    "name": "fullName",
    "email": "email",
    "signedUpAt": "date.past",
    "age": "number.int",
    "active": "boolean"
  }
}

Feed that spec to the generator and it returns a JSON array of records, each field filled with 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 value of this approach is that the spec is the whole contract. Adding a field, bumping the count, or swapping a type is a one-line change, and the spec doubles as documentation of what your records look like. Common types worth knowing: 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 in the Browser

For quick, one-off data you don't need to write any code at all. Paste a field spec, choose how many records you want, and copy the resulting array straight into a fixture file or a fetch mock.

The generator runs entirely in your browser — nothing is uploaded — and it's deterministic: the same spec text produces the same data every time, which is exactly what you want when a test asserts against specific values. If the output needs a final polish, pass it through the JSON Formatter to pretty-print it, or the JSON Minifier to shrink it into a single line for inlining. And before you commit a large fixture, a quick pass through the JSON Validator confirms it actually parses.

Faker Libraries in JavaScript and Python

When you need mock data inside a test suite or a seed script — with loops, conditionals, and relationships between records — reach for a faker library. These give you programmatic control that 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 expose hundreds of providers (addresses, companies, credit-card-shaped numbers, IP addresses, lorem text) and support locales, so you can generate German names or Japanese addresses when you need to test internationalization. The Python snippet uses the json module to serialize; the JavaScript one relies on JSON.stringify.

Generating from a JSON Schema

If you already maintain a JSON Schema for your API — for request validation or documentation — you can generate mock data directly from it instead of writing a separate spec. The json-schema-faker library reads a schema and produces a conforming instance, respecting 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));

The advantage is a single source of truth: the same schema that validates real requests generates the mocks, so your test data can never drift out of sync with your contract. If you don't have a schema yet, derive a starting point from a sample payload with the JSON Schema Generator, then hand-tune the constraints. For a deeper treatment of the schema language, see the JSON Schema guide.

Comparing the Approaches

Each method trades control against convenience. Pick based on where the data lives and how much logic it needs.

• Reach for an online generator when you want data in ten seconds and don't need it to change dynamically.
• Reach for a faker library when the data lives in code — a test factory, a seed script, records that reference each other.
• Reach for JSON Schema faker when you already have a schema and want your mocks to stay in lockstep with it.

Best Practices for Mock Data

Use deterministic seeds

Random data that changes on every run makes tests flaky and diffs noisy. Seed your generator so the output is reproducible — a fixed seed turns "generate five users" into a stable fixture you can assert against. Both faker libraries take a seed; the online generator is deterministic on the spec text itself.

Match realistic distributions

Uniformly random data hides bugs that real data would surface. If 95% of your users are active and 5% are churned, generate that ratio — a weighted choice, not a coin flip. Ages clustered around a plausible mean, order totals that follow a long tail, timestamps concentrated in business hours: realistic shape is what makes mock data catch real problems. Faker libraries let you express these with helpers like weighted picks and bounded ranges.

Never use real PII

Keep specs in version control

Treat the field spec or the factory code as a first-class artifact. Committing it means anyone can regenerate the exact fixtures, review changes to the data shape in a pull request, and trace why a test expects a particular value. If you need to keep two versions of a fixture in sync, the JSON Diff tool makes the delta obvious.