Fake Data Generator
Generate rows of synthetic names, emails, and phone numbers for testing forms, databases, or demos, entirely made up, entirely in your browser.
About the Fake Data Generator
Every name, email, and phone number this tool produces is randomly assembled from lists of common first and last names combined by chance, none of it is looked up from a real person or dataset. It's meant for filling out test forms, seeding a demo database, or checking how a UI handles a batch of realistic-looking rows, not for representing or impersonating anyone real.
- Names, a first and last name are picked at random and paired together.
- Emails, derived from the generated name (apostrophes and spaces stripped) plus a clearly fake placeholder domain.
- Phones, formatted as a US-style (XXX) XXX-XXXX number, with the area code's first digit never 0 or 1, matching real numbering rules.
- Randomness, every pick uses the browser's cryptographic random number source, not a predictable generator.
Why the domains never resolve to a real inbox
The domains used for generated emails, example.com among them, are deliberately chosen to be non-functional placeholder domains rather than real ones a message could actually reach. example.com specifically is reserved by IANA (the body that manages internet address assignments) exactly for documentation and testing purposes, it's guaranteed to never be sold or assigned to an actual operator, which is precisely why it shows up constantly in tutorials, API docs, and test data generators like this one. Generating fake data that could plausibly hit a real person's inbox would defeat the entire purpose of a synthetic test dataset.
Cryptographic randomness, and why rejection sampling matters here
Every random pick uses crypto.getRandomValues rather than Math.random(), which is a stronger, less predictable source of randomness, but strength alone isn't enough to guarantee a fair pick. Naively reducing a random 32-bit number to a smaller range with the modulo operator introduces a subtle bias, when the range doesn't divide evenly into the total number of possible random values, the lowest few numbers in that range end up very slightly more likely than the rest. This generator avoids that with rejection sampling, discarding and re-rolling any random value that falls in the leftover, unevenly-distributed portion of the range before applying modulo, so every name, digit, and domain in the output has a genuinely equal chance of being picked.
The phone numbers follow real formatting rules, with one gap
US phone numbers follow the North American Numbering Plan, which requires an area code's first digit to be 2 through 9, this generator enforces that rule specifically, an area code here never starts with 0 or 1. The three-digit exchange code that follows the area code is subject to a similar real-world restriction that this generator doesn't currently enforce, so a generated number could technically show an exchange starting with 0 or 1 in a way a genuinely assigned number never would. It's a minor gap that doesn't affect the numbers' usefulness as placeholder data, worth knowing only if the output needs to pass a stricter format validator that checks the exchange digit specifically.
Copying rows out as CSV
The "Copy as CSV" button builds a plain comma-separated file from whichever columns are currently enabled, with a header row included automatically so the copied data pastes cleanly into a spreadsheet or straight into a script that expects a header. Toggling the email and phone checkboxes off before copying trims the CSV down to just the name column, useful when only one specific field is actually needed for a given test rather than the full row.
Common uses beyond just filling out a form
Seeding a demo database with a batch of plausible-looking rows is one of the more common reasons to reach for this, a table that's empty or has one obviously fake test entry looks unfinished in a demo, twenty rows of varied names and contact details makes the same interface look like it's handling real data. It's also useful for load-testing a form's validation logic against a range of realistic inputs at once, or for taking product screenshots that need populated-looking data without using any actual customer or user information, which matters for privacy compliance in a way that copying real user records for a screenshot never would.
Frequently Asked Questions
Could a generated email address accidentally reach a real person?
No. The domains used, including example.com, are reserved placeholder domains that IANA guarantees will never be assigned to an actual operator, specifically so they're safe to use in documentation and test data without any risk of reaching a real inbox.
Why does this tool use crypto.getRandomValues instead of Math.random()?
It's a stronger, less predictable source of randomness, and combined with rejection sampling, it avoids a subtle bias that a naive modulo reduction would introduce. Every name, digit, and domain has a genuinely equal chance of being selected as a result.
Are the generated phone numbers fully compliant with real numbering rules?
Mostly. The area code correctly never starts with 0 or 1, matching real North American numbering rules. The exchange code that follows doesn't currently enforce that same restriction, so it's a close but not perfect match to how real numbers are assigned, which doesn't affect its usefulness as placeholder test data.
Is this data safe to use for testing without privacy concerns?
Yes. Every name, email, and phone number is randomly assembled from generic name lists and placeholder domains, none of it is looked up from or tied to a real person, and everything is generated locally in the browser without any data being sent to a server.
Can I copy just the names without email and phone columns?
Yes. Unchecking the email and phone checkboxes before copying trims the CSV output down to just the name column, useful when only one specific field is needed for a particular test rather than the full row.
Why generate fake data instead of using real user records for a demo or screenshot?
Using real customer or user data for a demo or screenshot raises privacy and compliance concerns that synthetic data avoids entirely. A batch of realistic-looking but entirely made-up rows makes an interface look populated and real without exposing any actual person's information.