Safe fake names, emails and phone numbers for test data and fiction

Why real-looking data is a problem

Placeholder data leaks out of its box. A staging environment sends a "welcome" email to the address in a fixture. A screenshot for a blog post shows a phone number. A story prints a number that rings in someone's kitchen. If the domain is real, mail goes to its owner. If the number is real, somebody picks up.

The fix is not to invent something that looks unlikely. It is to use values that are reserved for exactly this purpose.

Safe email domains

RFC 2606 reserves a handful of names for documentation and tests. You can use them without asking anyone and without fear that someone owns them:

Things that look safe and are not: mail.sample, inbox.demo, test.mail, test.com, email.com. The first three use endings that are not reserved and could be delegated to someone at any time; test.com and email.com are real, registered domains. Anything ending in a real provider's name belongs to that provider's users. I only use the three example domains in fixtures, and I use .test or .invalid when a hostname must not resolve.

One more rule: reserved does not mean "send freely". Mail to example.com goes nowhere useful, so keep placeholder addresses out of any flow that actually sends messages, or point those flows at a local mail catcher.

Turning a name into an email address

A generated person should have an address that matches the name, and it must be a valid local part. Spaces, apostrophes and accented letters are the usual breakers. The rule I use: lowercase, map special letters to ASCII, strip combining marks, keep letters and digits only, join given and family name with a dot.

Add a two-digit number if you need unique addresses, for example [email protected]. The generator adds the number only when two people in one batch would otherwise share an address, and it picks one of the three example domains at random.

Keep the original name with its apostrophe and accents in the name field. Test that your database, your CSV import and your PDF output show "O'Brien" and "Nguyễn" correctly. Those two cause more failures than any random string. For the cultural reasons behind such names, see name order and surnames around the world.

Safe phone numbers

Phone numbers are harder, because only some countries publish fictional ranges. In the North American Numbering Plan only 555-0100 to 555-0199 is reserved for fiction; other 555 numbers are used for directory and information services, so a random "555-1234" is not safe. Regulators in the UK, France, Germany and Australia publish their own drama ranges, compiled in the fictitious telephone number reference.

For Spain, Italy, Brazil and Japan the reference I rely on lists no fictional range. The tool leaves the phone field empty for those countries and says so, instead of inventing a number that could be real. A blank is honest; a plausible-looking guess is not.

Match the city and the number. If a person lives in Manchester, a London drama number looks wrong to a careful reader or a QA tester checking that area codes make sense. The tool picks a range that fits the city.

Consistency checks that catch real bugs

Good placeholder people are internally consistent. A persona aged 30 whose birthday says otherwise will fail any validation that compares the two, or worse, will pass the wrong test.

• Age follows the birthday. Age is today's year minus the birth year, minus one if the birthday has not happened yet this year. Someone born on 15 December is a year younger than their year difference on 8 October. The tool picks a birth date first and calculates age from it with one shared function, for ages 18 to 75.
• Birthday is a real date. Any day of the month is valid, not just 1 to 28. Test 29 February, and 31 January.
• Zodiac sign follows the date if you display one, with the boundary days handled correctly: 19 January is Capricorn, 20 January is Aquarius.
• Email matches the name and phone matches the city.

What never to fake

Do not generate card numbers, bank accounts, social security numbers, passport numbers or any other identity numbers, and do not use a real person's data as a template. These formats are real, and a made-up number can be somebody's actual number. If you need payment test data, use the test card numbers that your payment provider publishes for its sandbox. The tool does not generate any of these.

A checklist you can paste into your pull request

1. All emails use example.com, example.net or example.org (or .test and .invalid for hostnames).
2. Phones come from a published fictional range for the country, or are empty.
3. Age agrees with the birthday.
4. Test names include an apostrophe, a space in the surname, and a non-ASCII letter.
5. No card, bank, tax or ID numbers appear anywhere.
6. Staging cannot send real mail to placeholder addresses.

If you are just naming characters for a story, the same domain and phone rules apply when a character's email or number appears on the page. For picking the names themselves, see how to name a character.