Fake Data Generator

about this tool

Nothing here can reach a real person

Test data escapes. It ends up in screenshots, in bug reports, in a staging database someone points at a live email service, and occasionally in a mailshot that should never have gone out. So every value that could collide with something real is drawn from a range that was set aside for exactly this purpose.

Email addresses use example.com and its siblings, reserved by RFC 2606 and guaranteed undeliverable. Phone numbers come from 07700 900000 to 900999, which Ofcom reserves for use in television and film precisely so that nobody gets called; the phone number parser reads them as the right length but not a range in use. IP addresses use the documentation ranges from RFC 5737 and the 2001:db8:: prefix from RFC 3849. National Insurance numbers use the QQ prefix, which is never issued. Card numbers are built on the prefixes the payment schemes publish for testing.

That is a deliberate choice over generating something that merely looks plausible. A plausible phone number belongs to somebody.

The checksums are real

An IBAN here passes the mod-97 check, and a card number passes Luhn. Data that fails validation is useless for testing validation: you cannot tell a working form apart from a broken one if every value is rejected either way.

The bank code inside each IBAN is ZZ followed by letters, which no real institution uses, so the number is structurally valid and cannot address an actual account. The IBAN validator passes it and shows its parts.

The same seed gives the same data

Generation is seeded rather than random, so the same columns, row count and seed always produce the same set. That matters for a fixture: a test that depends on the third row still works tomorrow, and a colleague running the same settings sees the same thing. Press New data when you want a different draw.

Four ways out

The table is for looking at. JSON and CSV are for loading somewhere. SQL produces a single INSERT statement, with numbers and booleans left unquoted and apostrophes escaped, so a name like O'Brien does not break the statement.

To reshape the output, JSON to CSV converts between the two, and the CSV viewer opens the result as a table. For identifiers alone, the UUID generator makes them in bulk.

The SQL output is one long line per row; SQL formatter will lay it out if you need to read or edit it.

questions

Is the generated data safe to use publicly?

That is the point of it. Emails use the example.com domains reserved by RFC 2606 and can never be delivered, IP addresses come from the RFC 5737 and 2001:db8:: documentation ranges, card numbers pass the Luhn check on published test prefixes, IBANs have correct mod-97 check digits on a bank code that does not exist, and national insurance numbers use the reserved QQ prefix.

Will the card numbers work anywhere?

They are structurally valid — the right length with a correct check digit, so a form that validates the format will accept them — and they belong to no account. Use them to test validation, never to test a real payment.

Can I get the same data again?

Yes. Generation is seeded, so the same seed and the same fields produce the same rows every time. That is what makes it usable for a test fixture, where a dataset that changes on every run makes failures impossible to reproduce.

What formats can I export?

A table to read, JSON for a fixture or an API stub, CSV for a spreadsheet or bulk import, and SQL INSERT statements for seeding a database directly. Up to 500 rows per run.

Why not just use real data for testing?

Because a copy of production in a test environment is one of the most common ways personal data leaks, and in most jurisdictions it needs a lawful basis you probably do not have for testing. Generated data avoids the question entirely.