Generating fake data for a form, a demo or a test fixture looks harmless until the fake phone number turns out to belong to somebody. Random digits are not safe digits. There are reserved ranges set aside by regulators and standards bodies precisely so that invented data can never reach a real person, and a generator that ignores them is producing a liability rather than a placeholder.
A phone number generated by picking ten random digits is a valid phone number. If the format is right, it dials.
The same applies to email addresses. A random string at a real domain is deliverable, and it will either bounce or land in a stranger's inbox. Put a few hundred of those in a test fixture that later runs against a live mail server and you have sent mail to people who never asked for it.
This is not a hypothetical failure mode. It is the ordinary consequence of test data escaping from the environment it was written for, which happens constantly: a staging database restored to production, a demo account left with real sending enabled, a screenshot posted publicly with the data visible.
The fix is not better randomness. It is choosing from ranges that cannot reach anyone.
North American numbering reserves 555-0100 through 555-0199 for fictional use. Those are the numbers film and television are supposed to use, and they do not connect to a subscriber.
The wider 555 prefix is often assumed to be entirely fictional and it is not: parts of it have been allocated for real services. Only the 01xx block is guaranteed.
In the United Kingdom, Ofcom reserves ranges for drama use, including 07700 900000 to 07700 900999 for mobile numbers. Those are the ones a British production is meant to use on screen.
The phone number generator here draws from those reserved blocks rather than from the full numbering space. That constrains the variety of the output, which is the correct trade: a test fixture does not need a million distinct numbers, and it does need every one of them to be unreachable.
RFC 2606 reserves a small set of domain names for documentation and testing, and example.com is the best known of them. Alongside it are example.net, example.org and the reserved top level domains .test, .example, .invalid and .localhost.
These are not registered to anyone and they are never going to be. Mail addressed to them does not reach a person, and code that accidentally resolves them fails in a way that is obvious rather than silent.
The email generator uses them for the domain part, so the addresses it produces look realistic, parse correctly against a validator, and cannot be delivered.
Using a real domain for test addresses is the common mistake, and it is worse than it appears: the mail does not vanish, it arrives somewhere, and the owner of that domain has to deal with it.
The same principle covers network addresses. RFC 1918 sets aside three ranges for private use: 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255.
Addresses in those ranges are not routed on the public internet. An address generated from one of them cannot reach a stranger's machine, which is exactly what a test fixture needs.
The IP address generator uses them. A generator that picked freely from the whole address space would produce addresses belonging to real hosts, and code that connected to them during a test would be making unsolicited connections to third parties.
That is a different and more serious category of problem than a bounced email, and it is entirely avoidable by using the ranges that were reserved for it.
There is no reserved range for names, which makes the fake name generator and the pen name generator different from the three above.
Any plausible name belongs to somebody. Combining a common first name and a common surname will produce real people by coincidence, and there is no way to avoid that.
What you can avoid is using generated names in contexts where they will be read as claims about a person: a testimonial, an author byline, a review, a quote. That is where a coincidental match stops being harmless and starts being an attribution to someone who never said it.
Use generated names for form fixtures, seed data and demo accounts. Do not use them anywhere a reader would take the name as identifying a real individual.
Here the requirement inverts. Test data should be predictable and constrained; a password or an identifier should be neither.
The difference is the source of randomness. A general-purpose random number function is designed to be fast and statistically even, not to be unpredictable. Given enough output, its future values can be derived. For a dice roll that is fine. For a password it is not.
The password generator and the UUID generator both draw from the browser's cryptographic random source rather than the ordinary one. That source is designed so that output cannot be predicted from previous output.
Everything runs in your browser, so a generated password is never transmitted anywhere. That matters more than it sounds: a password generator that produces the value on a server has, by construction, seen your password.
Realistic enough to exercise the code, obviously fake enough that nobody mistakes it for production data.
That second half is the part people skip. A record that looks entirely plausible is dangerous in a way that an obvious placeholder is not, because it will be treated as real when it surfaces somewhere unexpected.
So reserved ranges do double duty. They guarantee the data cannot reach anyone, and they signal to the next engineer that the row is synthetic. A 555-0142 number is recognisable on sight.
Add volume with the random word generator for text fields and lorem ipsum for body copy, which has the same property: nobody reads lorem ipsum and thinks it is real content.
Not everything on the site is for fixtures. The team name generator, gamertag generator and random quote generator exist to break a blank page rather than to fill a database.
Those have a different failure mode: a generated name may already belong to an existing team, product or account. Check before you commit to one, the same way you would check any name you invented yourself.
The random hex colour generator and random number generators are the closest to pure utility, with nothing to collide with.
All of them run locally in the browser, which means nothing you generate is logged anywhere, and none of them requires an account.
Are the phone numbers in a reserved fictional range? If they are ten random digits, they are not.
Are the email domains from the RFC 2606 set? A real domain means deliverable mail.
Are the IP addresses private? A public address in a test means real connections.
Are any generated names presented as attributions, testimonials or quotes? If so, replace them with something obviously synthetic.
Are the passwords in the fixture ones that could ever be used for real? A password generator is for real passwords; a fixture should carry an obvious dummy value instead.
Five questions, and they catch the cases where synthetic data stops being synthetic the moment it leaves the environment you wrote it for.
The instinct with a generator is to produce ten thousand rows because the button is there. Most test suites are better served by a few dozen.
A large fixture is slower to load, harder to read when a test fails, and more likely to be treated as real data by whoever finds it next. It also increases the chance that one of the generated values collides with something real, which is the risk the reserved ranges exist to bound.
Small fixtures are easier to reason about. If a test fails on row four, you can read row four.
Where volume genuinely matters, such as load testing or pagination, generate it at run time from a seed rather than committing it to a file. That keeps the repository small, makes the data reproducible, and means there is no large body of plausible-looking personal data sitting in version control where it will outlive the test that needed it.
No. Only 555-0100 through 555-0199 is reserved for fictional use in North American numbering; other parts of the 555 prefix have been allocated for real services.
RFC 2606 reserves it and a few related names for documentation and testing. They are registered to nobody, so mail addressed to them cannot reach a person.
They are drawn from the browser's cryptographic random source rather than an ordinary random function, and they are generated locally, so the value is never transmitted anywhere.