Random Data Generator

Random Data Generator

Generate fake names, emails, addresses, phone numbers for testing. Create realistic test data in JSON/CSV. Free mock data generator online

Test fixtures with hard-coded "John Doe / john@example.com" entries are easy to spot in screenshots and lead to lazy edge-case coverage. Realistic fake data — actual-looking names, structurally-valid emails, locale-appropriate phone numbers, plausible addresses — exercises your code paths the way real data will. This generator produces fake records in 30+ locales, supports referential integrity for related fields (a Polish person gets a Polish name, a Polish-format phone, and a Warsaw-or-similar city), and exports to JSON, CSV, SQL INSERT, or TypeScript fixtures.

What "realistic" actually requires

  • Names sampled from real frequency distributions per locale. "Mary" is more common than "Mehetabel" in English; "Anna" is more common than "Ahsoka" in Polish.
  • Emails using safe domains (example.com, test.org, dispatch.test) — RFC 6761 reserves these for testing so no real user gets your test mail.
  • Phone numbers in valid formats per locale: +1 (NPA) NXX-XXXX for US, +48 NN NNN NN NN for Polish, +44 NNNN NNNNNN for UK. Some formats reserve specific ranges as "fictional" (US 555-0100 to 555-0199).
  • Addresses with locale-correct street naming (Strasse for Germany, ulica for Poland, "Avenue" for US), real ZIP codes that exist in real cities, and city names that match the country.
  • Dates of birth distributed by demographic — birth year follows the actual population pyramid, day-of-month is uniform, weekday avoidance for "registered" timestamps (more signups on Tuesdays than Sundays).

Working example: 5 user records, Polish locale

Input

Locale: pl-PL, count: 5, format: JSON

Output

[
  {
    "firstName": "Katarzyna",
    "lastName": "Nowak",
    "email": "katarzyna.nowak.42@example.org",
    "phone": "+48 22 555 17 83",
    "city": "Warszawa",
    "postalCode": "00-001",
    "dateOfBirth": "1988-03-14",
    "pesel": "88031400000"      // invalid checksum on purpose
  },
  {
    "firstName": "Piotr",
    "lastName": "Wiśniewski",
    "email": "p.wisniewski.91@dispatch.test",
    "phone": "+48 12 555 22 44",
    "city": "Kraków",
    "postalCode": "30-100",
    "dateOfBirth": "1991-11-23",
    "pesel": "91112300000"
  },
  ... 3 more ...
]

PESEL numbers in this output are structurally formatted (11 digits, first 6 = YYMMDD) but the checksum is deliberately invalid so the values cannot be confused for real IDs. If you need valid checksum (e.g., for testing your validator), generate explicitly with that option.

Fields and their gotchas

  • Names — Western "first / last" is locale-specific. Asian conventions put family name first; Spanish has paternal and maternal surnames; some cultures have one name. If you target users globally, store names as one field or a list, not "first/last".
  • Emails — use the @example.com / @example.net / @example.org or @test domains. RFC 2606 reserves them. Avoid @gmail.com or any real domain in test fixtures — risk of leaking to real users if test data escapes.
  • Phone numbers — many locales have reserved fictitious ranges (US 555-XXXX in TV/movies; UK 020 7946 0xxx; Poland has no formal reserved range but +48 22 555 XX XX is conventional).
  • Credit cards — for testing, use the test-card numbers published by Stripe / Adyen / Visa. Random "valid Luhn" numbers may collide with real cards (most digits are not in use; collisions are rare but possible).
  • IBANs — generate with valid country prefix + checksum; do not use random digits and call them IBANs. Test IBANs in some countries (DE89370400440532013000 = Deutsche Bank test account) are publicly documented.
  • Dates of birth — random uniform across "reasonable adult range" usually means uniformly distributed birth years 1940-2007 (for adults in 2026). Real signup pools skew younger; calibrate for your scenario.

When to reach for this tool

  • You are seeding a development database and want 1000 realistic-looking records without typing them.
  • You are demoing a feature and want screenshots that look real without showing real customer data.
  • You are stress-testing a search or filter with 10,000+ records and need varied data to exercise edge cases.
  • You are creating Cypress or Playwright tests and need fresh fixtures each run to catch hidden state dependencies.

What this tool will not do

  • It will not protect you from accidentally using real data. The generator produces fake records, but if you load fake data into a production database, the records become "real" from the system's perspective — and your support team will get confused emails from fictional Katarzyna Nowak. Always seed test environments only.
  • It will not generate data with referential integrity to your existing database. The "user" generated here has no relationship to your "order" table; for cross-table relationships, use a fixtures framework (Factory Bot, Faker integrated with your ORM) that knows your schema.
  • It will not be statistically perfect. Names come from frequency lists, addresses from sampled real ZIP codes, but the joint distribution (e.g., "what% of people named Anna live in Kraków") is not modeled.

Generation happens entirely in your browser using JavaScript's pseudorandom generator seeded for repeatability if requested. Generated data is yours to keep and never transmitted.

Frequently asked questions

Is the data really fake or could it match a real person?

Names and addresses are sampled from real distributions, so a generated record like "Anna Kowalski, Warszawa" describes many real people. The combination (name + DOB + email + phone) is randomly assembled and is statistically very unlikely to match a real individual. If your use case is "demo data for marketing", swap recognizable names (e.g., "Lewandowski") for less common ones to reduce association.

Can I generate valid SSN / NIP / PESEL with correct checksums?

Yes, with the "valid checksum" option. By default the tool deliberately produces invalid-checksum IDs so the data cannot be mistaken for real records. For testing checksum validators, switch to valid mode. Never use generated valid IDs in production — they may collide with real people.

How do I generate the same fake data on every test run?

Pass a seed. Same seed + same parameters = same output. Most fake-data libraries (Faker.js, Bogus, mimesis) support seeding. For database seeders, seed by record index so re-runs reproduce the same rows.

What's the safest "test email domain"?

example.com, example.net, example.org (RFC 2606), and the .test TLD (RFC 6761) are guaranteed never to be assigned. Email to any of them bounces, so no risk of sending to a real user by mistake. Avoid @yopmail.com or other "throwaway" services — they are real domains receiving real mail.

Do I need to include locale-specific characters (ł, ñ, ß) in names?

For realistic data, yes. For testing UTF-8 handling, encoding errors, sorting collation, and form validation, locale-specific characters are exactly the inputs your real users will provide. Omitting them gives a false impression of "tests pass".

Can I export to SQL INSERT statements?

Yes — pick the SQL output format. Generated INSERT statements use parameterized values; no SQL injection risk. For bulk imports, the COPY command (Postgres) or LOAD DATA INFILE (MySQL) of a CSV is faster than thousands of INSERTs.

Related tools

Last updated · E-Utils editorial team