Test Data Toolkit

Why use synthetic test data?

Copying production data into a test or staging environment is the easiest way to get realistic records, and the easiest way to leak personal data. A staging database usually has weaker access controls than production, gets shared with contractors, ends up in screenshots and bug reports, and is rarely deleted on schedule. Data protection laws such as the GDPR treat a copy of customer data in a test system exactly like the original.

Synthetic data avoids the problem. It looks and behaves like the real thing — names with accents and apostrophes, postcodes with spaces, two-surname Spanish names, addresses with apartment numbers — but it describes nobody. You can paste it into a ticket, commit it as a fixture or show it in a demo without a second thought.

What makes good test data

• Valid where it matters. A postcode has to match the country’s format, a UUID needs the right version bits, a routing number has to pass its checksum. Otherwise your tests only exercise the error path.
• Realistically messy. Real input has diacritics (Müller, São Paulo), long values, optional address lines and different name orders. Test data that is all John Smith, 123 Main St hides bugs that your first international customer will find.
• Harmless if it escapes. E-mails on reserved domains never reach an inbox. Phone numbers from fictional ranges never ring anyone. That matters when a test accidentally triggers a real notification.
• Easy to recognise. Using example.com addresses and 555 numbers makes test records stand out in logs and dashboards, so nobody mistakes them for customers.

How these tools keep data fictional

Every generator here follows the same rules. Street names and house numbers are built from generic words and random numbers; only cities, regions and postcode formats are real, so that validation and shipping-zone logic behave as they would in production. E-mail addresses use example.com, example.net, example.org or the reserved .test, .example and .invalid top-level domains. Phone numbers come only from ranges that regulators have reserved for films and TV — in the United States and Canada, the United Kingdom, Australia, France and Germany. For other countries the phone stays empty.

There are also things we deliberately do not generate: social security numbers, national ID numbers, tax IDs and passport numbers. A realistic-looking fake identity number can collide with a real person’s number, and these fields have no legitimate use outside the systems of the authorities that issue them. If your schema has such a column, fill it with an obviously invalid placeholder in your fixtures.

Validators for bank identifiers

Two tools work the other way round: they check data instead of creating it. The SWIFT code checker tests whether a BIC is well-formed — 8 or 11 characters, a valid ISO country code, and the special location codes for test and passive BICs. The routing number validator checks a US ABA routing number’s prefix and its 3-7-1 checksum, and can calculate the check digit for you. Both explain each step, which is handy when you write your own validation code, just like our IBAN checker does for IBANs.

Everything runs in your browser

The generators use your browser’s cryptographic random number generator (crypto.getRandomValues). The page loads one static data file with word lists, city lists and postcode formats; after that, nothing you generate or type is sent anywhere. That makes the tools safe for internal projects, and they keep working if your connection drops after the page has loaded.