{ }jsonkitOpen

How to generate mock JSON data for testing

7 min read · updated 2026-07-12

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.

A field spec: three records, six typed fields eachjson
{
  "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:

Generated output: a JSON array you can use right awayjson
[
  {
    "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.

Mock JSON Data GeneratorOpen the tool→

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

Generate an array of user records with @faker-js/fakerjs
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

The same records with Python's Faker librarypython
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.

Generate a record from an existing JSON Schemajs
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.

ApproachBest forControlSetup
Online generatorQuick fixtures, demos, one-off dataLow (fixed type list)None
Faker library (JS/Python)Test suites, seed scripts, relationshipsHigh (full code)Install a package
JSON Schema FakerTeams with an existing schemaMedium (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.

Frequently asked questions

What is mock JSON data?

Mock JSON data is generated fake data in JSON format. The records have realistic fields like names, emails, UUIDs and dates that look like production data but contain nothing real. Developers use it in tests, prototypes, demos and development databases.

How do I generate mock JSON data online?

Use a field-spec generator like the Mock JSON Data Generator. Write a spec that maps field names to types (for example id to uuid, name to fullName), set how many records you want, and it returns a JSON array. It runs in your browser, so no data is uploaded.

How can I make mock data reproducible across test runs?

Use a fixed seed. The Faker libraries in JavaScript (faker.seed(42)) and Python (Faker.seed(42)) produce identical output for the same seed. The JsonKit generator seeds itself from the spec text, so the same spec always gives the same data.

What's the difference between a faker library and a JSON Schema faker?

A Faker library (like @faker-js/faker or Python's Faker) is driven by code. You call functions to build each field, so you control the logic and relationships. A JSON Schema faker generates data from an existing JSON Schema, so your mocks stay in sync with the contract that validates real requests.

Is it safe to use real customer data as test data?

No. Real personal data in fixtures or shared test databases is a security and privacy risk, because it leaks into logs, screenshots and git history. Generate fresh mock data instead, or fully anonymize anything taken from production before you use it.

How many mock records should I generate for testing?

Enough to exercise the code path. Use a handful for unit tests that check specific values, dozens to fill a UI table and thousands for load or pagination testing. Generating data is cheap, so match the count to what each test needs instead of keeping one giant fixture.