Fake Data Generator — Realistic Mock Data for JSON, CSV, SQL, TypeScript

What is Fake Data Generator?

A fake data generator produces realistic-looking-but-synthetic records for testing, seeding development databases, and load-testing APIs. Unlike random junk (`asdf1234`), the values look like real ones: plausible names, valid-looking email domains, addresses that match locale patterns, phone numbers with correct country codes. This is what makes mock data useful — the tests exercise real parsing/validation paths, not just structural fields.

How to generate fake data

1. 1Pick a preset schema (User, Order, Product, Post, Employee, Address) or click Custom to compose your own fields.
2. 2For each field, choose a type: name, email, uuid, phone, address, date, number, boolean, category, url, image, custom regex, etc.
3. 3Set the row count (1-10,000) and locale (en, zh, ja, fr, es, de, and more).
4. 4Choose an output format: pretty JSON array, NDJSON (one object per line), CSV, or SQL INSERT statements.
5. 5Click Generate. Copy the result or download as a file — the data is deterministic per seed if you provide one.

Use Cases

Code Examples

import { faker } from "@faker-js/faker";

const users = Array.from({ length: 100 }, () => ({
  id: faker.string.uuid(),
  name: faker.person.fullName(),
  email: faker.internet.email(),
  createdAt: faker.date.recent().toISOString(),
}));

from faker import Faker
fake = Faker("en_US")

users = [{
  "id": fake.uuid4(),
  "name": fake.name(),
  "email": fake.email(),
  "created_at": fake.iso8601(),
} for _ in range(100)]

INSERT INTO users (id, name, email, created_at) VALUES
  ('9a3f-…', 'Sarah Chen', 'sarah.chen@example.com', '2026-03-14T09:22:11Z'),
  ('2b81-…', 'Marcus Alvarez', 'marcus.a@example.com', '2026-03-14T09:22:12Z');

Key Concepts

Seeded vs. random

With a seed (any string), the same schema + row count reproduces byte-for-byte the same data every run. Use seeded generation for tests (deterministic assertions) and unseeded for exploratory demos.

Locale-aware fields

A name in `zh_CN` looks like `王小明`; in `fr_FR` like `Marie Dupont`; in `ar` like `أحمد محمد`. The same is true for addresses, phone number formats, and postal codes. Locale matters — English mock data will fail any real i18n test.

PII vs. synthetic data

Real user records contain PII (personally identifiable information) governed by GDPR / CCPA / LGPD. Synthetic data resembles PII in shape but is guaranteed to not identify anyone — safe to commit, share, and log.

Reserved test emails

Domains `example.com`, `example.org`, and `example.net` are IANA-reserved for testing (RFC 2606). Using them for mock data guarantees no accidental email delivery to a real person.

Tips & Best Practices

• ▸Include edge cases explicitly: an empty string, a very long name (255+ chars), Unicode with combining marks (`é` vs `é`), and a null/undefined. Real data has them; your test data should too.
• ▸For SQL INSERTs, keep row count under 1000 per statement — most databases have a limit and your import will fail past it. Use multiple statements or a `COPY` / `LOAD DATA` command for larger sets.
• ▸When anonymizing production data, don't just replace fields — replace *and* shuffle them, so an attacker can't correlate 'user 1 in mock DB' with 'user 1 in real DB' by row order.
• ▸Generate booleans with realistic distributions, not 50/50. Most real fields (`is_verified`, `is_paid_customer`) skew heavily in one direction — matching that catches UI bugs that only appear at extreme ratios.