Fake Address Generators for Form Testing: What Passes Validation and What Doesn't

A fake address generator will hand you (012) 345-6789 without blinking. Your validator rejects it in about a millisecond, and then you lose twenty minutes deciding whether the bug is in the data or in you.

It's in the data. Most identity generators build phone numbers by filling a mask with random digits, and the North American plan forbids some of those digits in positions the mask knows nothing about.

That's the small problem. The bigger one is the shortcut teams reach for instead: a dump of the production users table into staging, because it's realistic and it's already there. Under GDPR that copy is its own processing activity, and it sits in the higher of the two fine tiers.

What follows is which generated fields survive contact with a real validator, which ones will quietly email a stranger, and the specific gaps where generated data is too clean to catch anything. Everything said about our own generator comes from reading its source.

Copying production into staging is processing, not a backup

Article 5(1)(b) of the GDPR says personal data is collected for specified, explicit and legitimate purposes, and not further processed in a manner incompatible with those purposes. Someone who created an account to buy a thing did not agree to become a row in your load test.

The copy does not inherit the original lawful basis either. New purpose, new basis needed, and "the developers wanted realistic data" is not one of the six.

The fine tiers are worth getting right, because people assume every GDPR penalty is the same size. Article 83(4) covers security and data-protection-by-design duties: up to 10 million euro or 2% of total worldwide annual turnover, whichever is higher. Article 83(5) covers the basic principles in Article 5 and doubles both numbers, to 20 million euro or 4%. Purpose limitation lives in the expensive band.

Then there's the unglamorous practical argument. Staging is nearly always the weaker environment: broader database credentials, debug logging left on, error pages that print queries, occasionally a URL nobody remembered to take off the public internet. Copying production there moves the valuable data to the building with the worse lock.

"We scrambled the names" is pseudonymisation, and it still counts

Article 4(5) defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, held separately.

Recital 26 then shuts the door people try to walk through: pseudonymised data that could be attributed to a person by using additional information is still information about an identifiable person. Only genuinely anonymous data falls outside the regulation.

The test it sets is "all the means reasonably likely to be used, such as singling out". A table where you replaced the names but kept real postcodes, real dates of birth and real order histories singles people out without much effort. One row with a birthdate, a postcode and a purchase of something unusual is a person, name column or not.

Generated data avoids the argument entirely, for a boring reason. There's no original to link back to.

What a fake address generator actually gives you

Ours covers six locales, the US, UK, Canada, Australia, Germany and France, and returns twenty fields per identity: first, last and full name, gender, date of birth, age, national ID number, email, phone, street, city, state or region, postcode, country, company, job title, salary, username, password and a personal website.

It runs in the browser. Nothing about the identity reaches a server, and the only request the page makes is a counter that increments a usage number. When you need one believable record to paste into a form you're debugging, you can generate a throwaway identity and copy it out as JSON.

The honest limitation: one identity per click. No bulk export, no CSV of five thousand rows. For filling a form by hand or building a handful of fixtures it beats writing a seeder. For volume you want a seeded library inside the test suite instead, and a fixed seed buys you reproducible failures, which a generator in a browser tab can never give you.

The phone numbers will fail a real validator

The generator replaces every # in a per-country mask with a random digit from 0 to 9. The US mask is (###) ###-####.

The North American Numbering Plan does not allow that. Numbers run NXX-NXX-XXXX, where N has to be 2 through 9. Both the first digit of the area code and the first digit of the exchange are constrained, for a reason that predates all of us: a leading 1 signals long distance and a leading 0 reaches an operator, so neither can start a code.

Random digits satisfy both constraints 64% of the time. More than a third of the US numbers you generate are malformed before you even look at them, and libphonenumber will tell you so.

Handy if you're testing that bad input gets rejected. Irritating if you needed two hundred valid numbers for a seed script.

If what you want is numbers that can never ring a real person, NANPA reserves 555-0100 through 555-0199 for fictional use. That block is the only officially safe one, a hundred numbers per area code. The rest of the 555 range is assignable, so the film convention gives you far less protection than people think.

ID numbers are the right shape and nothing else

The US mask is ###-##-####. The Social Security Administration has never issued a number with an area of 000 or 666, and the whole 900-999 range is permanently excluded. Random digits produce all three. Since randomization started on 25 June 2011 the first three digits carry no geographic meaning anyway, so shape is all anybody can check.

The UK is messier. The generator's National Insurance mask is two random letters, six digits, one random letter. Real NI numbers are far pickier than that: D, F, I, Q, U and V never appear in either letter position, O is never the second letter, the prefixes BG, GB, KN, NK, NT, TN and ZZ are never issued, and the suffix is only ever A, B, C or D.

That last rule alone does most of the damage. A random final letter lands in A to D roughly one time in seven, so the majority of generated NI numbers carry a suffix HMRC would never have issued.

Fine, as long as you know which side of the test you're standing on. Need well-formed input? Generate a few and bin the rejects. Need malformed input to prove your validator actually bites? You have a free supply.

Real email domains are the actual footgun

The generator picks from gmail.com, yahoo.com, outlook.com, hotmail.com, protonmail.com, icloud.com and a few others, then builds something like [email protected].

That address may belong to somebody.

The failure mode writes itself. A staging job with working SMTP credentials fires welcome emails, or password resets, or invoices, at several hundred addresses that everyone in the room had been calling fake. The addresses were fake. The mailboxes were not, and the replies come back to a real support queue.

RFC 2606 reserved names for this and they cost nothing to adopt: the top-level domains .test, .example, .invalid and .localhost, plus example.com, example.net and example.org. None of them resolve. Keep the generated local part if you like the realism, swap the domain, move on.

Same warning applies to the website field, which comes out as www.firstnamelastname.com. www.jamessmith.com is a registered domain belonging to someone who did not volunteer for your integration test.

Addresses are city-consistent but not deliverable

Each city in the generator carries exactly one hardcoded postcode. New York is always 10001. Toronto is always M5V 1A1. London is always SW1A 1AA. The street number is random between 1 and 9999, and the street name comes from a fixed list per country.

So the address sails through a naive city-to-postcode cross-check and fails anything real. Point it at Loqate, Google's Address Validation API or a carrier rate quote and it bounces, because 4821 Maple Dr does not exist inside the 10001 range. If your form calls a verification provider, you need that provider's own test fixtures, not a generator.

London is a good illustration of why generated postcodes deserve a second look. SW1A 1AA is Buckingham Palace, a large-user postcode Royal Mail assigned to that single address. It is real and it is deliverable. If a test harness ever posts something physical, that is where it goes.

Pick Germany or France when you want to break your encoding

The US, UK, Canadian and Australian name lists are pure ASCII. Every one of them passes through a misconfigured latin1 column without leaving a mark, which is how an encoding bug survives an entire test suite and then surfaces the day a real customer signs up.

The German and French lists don't. German surnames in there include Müller, Schröder, Krüger and Köhler, and the street list carries Hauptstraße and Bahnhofstraße with the ß. French gives you Chloé, Inès, Léa and Rue Émile Zola.

Fastest encoding test I know: generate one German identity, run it through registration, then read the row straight back out of the database rather than off the page. If Müller comes back as Müller you have a latin1 column or a connection charset that disagrees with the application. Thirty seconds, no test framework involved.

Where generated data is too clean for form testing

Every generator has a shape, and the shape is defined by what it will never produce. Ours:

The apostrophe gap is the one I'd close by hand. O'Brien is the oldest input in the book for breaking careless string handling and unparameterised queries, and no locale here produces one.

The date-of-birth cap matters more than it looks. A form that accepts 28 February and chokes on the 29th in a leap year is a genuinely common bug, and this data will never find it, because the day is drawn from 1 to 28 in every locale.

A working order for fake address generator testing

1. Decide whether you need volume or variety. Under about fifty records, generate by hand. Above that, use a seeded library in your fixtures so failures reproduce.
2. Rewrite the email domain to example.com or your own catch-all before anything in the pipeline is able to send. Do this first, not after the incident.
3. Do the same to the website field, or drop it from the fixture.
4. Decide whether malformed phone and ID numbers are your test case or your obstacle, then filter in the direction you need.
5. Run at least one German or French identity down the full path to check encoding.
6. Hand-write the ugly cases the generator skips: an apostrophe, a leap-year birthday, an empty optional field, a very long string.
7. Keep payment fields separate. Card numbers follow per-gateway rules of their own, and for a pure front-end checksum test you can generate card numbers that pass a Luhn check instead of recycling a sandbox number that only behaves in one provider.

Step two is the one that prevents an actual incident. The rest of the list costs you an afternoon at worst.