Mock Data Generator
Generate realistic mock data (users, emails, addresses, dates) as JSON, CSV, or SQL. 7 locales.
Mock Data Generator
Runs entirely in your browser. Your input never leaves your device.
What next?
How it works
Why mock data matters
Hardcoded test fixtures like user1, [email protected], and 123 Main St hide bugs that only surface with realistic data. A name field that fits "Alice" overflows with "María de los Ángeles Gutiérrez-Hernández". A date field that works in the US breaks with European locale formatting. Good mock data exercises your code with realistic variety — varied string lengths, unicode characters, edge-case values — before real users do it in production.
This tool uses faker.js, the most widely used JavaScript fake-data library, running entirely in your browser.
Data categories
faker.js organizes fake data into modules. The ones developers reach for most:
Person — firstName, lastName, fullName, jobTitle, gender, bio. Locale-aware: a Japanese locale produces plausible Japanese names; a Brazilian locale produces Portuguese names.
Internet — email, userName, url, ip, ipv6, mac, password, domainName. Useful for user accounts, API logs, network records.
Location — streetAddress, city, state, country, zipCode, latitude, longitude. Mix with person data to build realistic user profiles.
Finance — amount, currencyCode, currencyName, accountNumber, creditCardNumber, transactionType. Great for e-commerce and fintech fixtures. Note: credit card numbers pass Luhn validation but are not real cards.
Company — name, catchPhrase, buzzPhrase, industry. Useful when seeding org or account records.
Date — past, future, between, birthdate, recent. Returns JavaScript Date objects; the tool serializes them as ISO 8601 strings in the output.
Lorem — word, words, sentence, paragraph, paragraphs. Classic lorem ipsum or realistic random English sentences.
JSON vs CSV output
JSON is the right choice when:
- Feeding data to a REST API or seeding a database via a migration script
- Your schema has nested objects (e.g., a user with an embedded address object)
- You're writing test fixtures for Jest, Vitest, or Playwright
CSV is the right choice when:
- Importing into a spreadsheet (Excel, Google Sheets)
- Loading into a database with
COPYorLOAD DATA - Sending to a business stakeholder who needs to review sample data
Nested JSON fields are automatically flattened for CSV output: { "address": { "city": "Austin" } } becomes a address.city column.
Seeding for reproducibility
By default, faker.js uses a random seed on each run, so every generation produces different data. If you need deterministic output — the same fake records every time you run your test suite — set a seed value. Any integer works; the tool passes it to faker.seed(n).
// Equivalent to what this tool does under the hood
import { faker } from '@faker-js/faker'
faker.seed(42)
const name = faker.person.fullName() // Always the same name with seed 42
Use a fixed seed in CI fixtures that get committed to your repo. Use a random seed (or no seed) when exploring what your UI looks like with varied data.
Locale-aware generation
faker.js has built-in locales for 60+ regions. Switching locale affects names, addresses, phone numbers, and some other fields. The en locale produces American English data by default. Other commonly used locales:
de— German names, German street addressesja— Japanese names (kanji + hiragana)pt_BR— Brazilian Portuguese names and CPF-style IDsfr— French names and addresseszh_CN— Simplified Chinese
This is especially useful when testing internationalization handling — if your app only gets tested with ASCII names, you won't catch encoding bugs until launch.
How many rows can I generate?
The browser handles up to roughly 10,000 rows comfortably without noticeable lag. Beyond that, both the generation loop and rendering the result in the UI start consuming significant memory. For very large datasets (100k+ rows), generate in smaller batches or use faker.js in a Node.js script:
import { faker } from '@faker-js/faker'
import { writeFileSync } from 'fs'
const rows = Array.from({ length: 100_000 }, () => ({
id: faker.string.uuid(),
name: faker.person.fullName(),
email: faker.internet.email(),
}))
writeFileSync('fixtures.json', JSON.stringify(rows, null, 2))
Practical use cases
API integration tests — generate 50 user objects, feed them to your POST endpoint in a loop, assert the response shape. Catches serialization bugs that fixed objects miss.
Database seeding — generate records matching your schema, then run them through your ORM's bulk-insert. Tests constraints, indexes, and triggers with realistic cardinality.
Demo environments — populate a staging database so stakeholders see a realistic-looking app, not empty tables or placeholder text.
Schema validation — pipe generated JSON through a JSON Schema or Zod validator. If the validator rejects it, either your schema is too strict or faker is generating edge cases your schema doesn't expect — both are useful findings.
UI stress testing — see how your tables, cards, and forms look with very long names, international characters, and unusual values before real users trigger them.
Privacy
faker.js runs entirely in your browser. No generated data is sent to our servers. All values are algorithmically produced — they are not real people's names or real email addresses.
FAQ
Is the generated data real? Could it accidentally match a real person?
No. faker.js constructs values algorithmically — it picks from word lists, applies formatting patterns, and combines components. The probability of accidentally generating a real person's name + email + address combination is astronomically low, roughly equivalent to a random string collision. That said, never use generated data in a production context that requires real identities.
What does setting a seed do?
A seed initializes faker's random number generator to a fixed starting state, so every run with the same seed produces identical output. This is critical for reproducible test fixtures — if your test asserts specific values, the fixture must be stable across runs. Use any integer as a seed. If you change the seed, you get a completely different (but again reproducible) dataset.
Can I generate nested JSON objects?
The current tool generates flat records per schema. For nested structures, use faker.js in a Node.js script where you can compose objects freely:
const user = {
id: faker.string.uuid(),
profile: {
name: faker.person.fullName(),
avatar: faker.image.avatar(),
},
address: {
city: faker.location.city(),
country: faker.location.country(),
},
}
Why do CSV and JSON row counts differ sometimes?
They don't — both modes generate the same number of records. What can differ is apparent row count if you open the CSV in Excel and Excel auto-converts values (e.g., a UUID that looks like a number gets truncated). The raw file is correct; the display is Excel's interpretation.
What's the maximum number of rows I should generate in the browser?
Around 10,000 rows is comfortable. Beyond that, the generation loop and JSON serialization start consuming noticeable memory and the UI may lag. For 100k+ rows, install @faker-js/faker via npm and run a Node.js script — it can generate millions of rows limited only by disk space.
How do I generate locale-specific data like Brazilian CPF numbers or German postal codes?
Set the locale to pt_BR or de in the locale dropdown. faker.js locale modules include region-specific formats for phone numbers, zip codes, and IDs. Not every locale implements every field — if a locale-specific implementation is missing, faker falls back to the base English value.
Can I use this for load testing?
Yes, with a caveat. This tool generates data in the browser for fixture files and seeding scripts. For load testing (sending thousands of requests per second), generate your fixture files here, then feed them to your load testing tool (k6, Artillery, Locust). Don't try to drive load testing from the browser directly.
Are credit card numbers generated here valid?
The numbers pass the Luhn algorithm (the checksum check) because faker generates them that way to look realistic. They are not real card numbers and will be rejected by any real payment processor. Never use them in a production payment flow.