Fake Data Generator

The birthday-paradox problem hiding in this generator

Names come from two fixed pools: 40 first names and 37 last names, giving 1,480 possible first/last combinations. That sounds like plenty until you apply the birthday paradox — the same math that explains why a room of 23 people has a 50% chance of two sharing a birthday out of 365 possible days. With 1,480 possible name pairs, generating just 50 records already carries roughly a 56% chance of at least one duplicate full name; at the maximum of 100 records, it's over 96%. Since the email field is derived from the same name pair, a duplicate name produces a near-duplicate email too (same local part, different random number and domain). If your test asserts that every generated record is unique, don't rely on the name field alone — check the id or enable the uuid field, which draws from a 2¹²²-value space instead of a 1,480-value one.

How to use this tool

1. Set the number of records with the slider.
2. Choose JSON or CSV output format.
3. Check the fields you want in each record.
4. Click Generate and copy the output.

What's actually random here, and what's fixed

This isn't Bogus or Faker.js running underneath — there's no dependency at all. It's plain C# picking randomly from small, fixed, in-memory string arrays: 40 first names, 37 last names, 20 cities, 17 countries, 15 companies, 15 job titles, and 8 email domains. That's intentional for a free browser tool — no external data file to load, no locale tables, instant generation — but it means the variety ceiling is much lower than a real fixture library. For property-based testing or anything that needs thousands of genuinely distinct identities, reach for Bogus in your actual test project; use this tool for quick manual seed data and UI mockups where realistic-looking is enough.

One inconsistency I left in on purpose, and one I didn't

The email field is deliberately derived from the same first/last name pair as the record's name field — [email protected] next to "Alice Smith," not some unrelated string — so a record reads as one coherent fake person rather than several disconnected random fields glued together. The phone number is the opposite case: it's always formatted as US-style +1-XXX-XXX-XXXX regardless of which country a record gets. Enable both country and phone together and you'll get records like a "France" entry with a US-formatted phone number — a real mismatch, not a display bug. If your test or demo specifically needs country-correct phone formats, generate the phone separately or strip the column before use.

Five real .NET use cases

1. Seeding a local dev database without running a full EF Core migration seed. Generate JSON here, paste it into a quick script or an EF Core HasData() call for a feature branch where you just need rows to exist, not statistically realistic data.
2. Populating Storybook or component-library demos. A user list or data table component looks far more convincing with "Carlos Mitchell, Solutions Architect, Berlin" than with "Test User 1" repeated ten times — and it surfaces text-overflow and truncation bugs that placeholder strings don't.
3. Writing xUnit or NUnit test fixtures that need plausible-but-arbitrary values. When a test genuinely doesn't care what the name is, pulling it from here is faster than hand-typing "John Doe" into every test method and avoids every test in the suite sharing the exact same hardcoded values.
4. Generating CSV import samples to test a bulk-upload feature. Toggle the format to CSV, generate a batch, and use it to confirm your CSV parser and validation handle realistic field combinations — including the occasional duplicate name from the pool above.
5. Load-testing form validation and table rendering with volume. Generate 100 records, paste into a form-array or table component, and check rendering performance and validation behavior under realistic row counts before it happens in production with real user data.