Test data that cannot hurt anyone
Most dummy data is only accidentally safe. Type a made-up mobile number into a test database and there is every chance it belongs to a real person; let a staging server send one email to a guessed address and you have contacted a stranger. This generator is built so that mistake is impossible. Every phone number comes from ranges the UK regulator Ofcom has permanently reserved for TV and radio drama: mobiles are drawn from 07700 900000 to 900999, and landlines from the reserved blocks in real area codes, such as 0113 496 0000 to 0999 for Leeds, 020 7946 0000 to 0999 for London, and 01632 960000 to 960999 for towns without their own drama block. Ofcom keeps these ranges out of allocation, so no provider can ever issue them to a customer. It is the same reason soap characters always seem to have 07700 numbers.
Emails get the same treatment. Every address ends in example.com or example.org, domains reserved by RFC 2606 for documentation and testing. They will never host a real mailbox, so even if your test environment fires off a thousand emails by accident, nobody receives anything.
What a record contains
Tick the fields you need: first, last and full names, email, UK mobile, UK landline, street address, town, postcode and date of birth for people, plus a company name for B2B shapes. Records are internally consistent. The email is built from the row's own name, the postcode uses the real postcode area for the row's town, and where the town has a reserved drama block, the landline uses its real dialling code. A Leeds row gets an LS postcode and an 0113 496 0xxx landline.
Why not just use real data?
Because a copy of production data is still personal data. Under UK GDPR, customer records sampled into a test or demo environment keep every legal duty they had in production: a lawful basis, access controls, retention limits, breach reporting. Test systems are usually the least protected part of an estate, which is exactly where you do not want real names and phone numbers sitting. Synthetic records sidestep the whole problem. A generated row describes nobody, so a leaked staging database is an embarrassment rather than a breach, and screenshots for demos, documentation and app store listings can show realistic looking data without blurring anything.
The same applies to seeding development databases, populating UI mockups, load-testing an import pipeline, or teaching a spreadsheet class. Any time you need rows that look plausible but must not be real, generated beats sampled.
CSV and JSON, ready to import
CSV output starts with a snake_case header row and quotes any value containing a comma, quote or line break, doubling internal quotes as RFC 4180 requires. That matters with this data: surnames like O'Brien pass through untouched, while a company such as "Hartley, Webb & Co" is quoted so its comma cannot split the column. Dates of birth use ISO YYYY-MM-DD so spreadsheets and databases parse them the same way. JSON output is an array of objects with camelCase keys, indented and ready to paste into a fixture file, and you can flip between the two formats without regenerating, the same rows are simply re-rendered.
Everything happens in your browser. The names are picked by the cryptographic random number generator on your own device, nothing is uploaded, and no record of what you generate exists anywhere once you close the tab.
Frequently asked questions
Can the phone numbers ever ring a real person?
No. Every number comes from ranges Ofcom has reserved for TV and radio drama, such as 07700 900000 to 900999 for mobiles and blocks like 0113 496 0000 to 0999 for landlines. Ofcom keeps these ranges out of normal allocation, so no communications provider can issue them to a real customer.
Why do all the emails end in example.com or example.org?
Those domains are reserved by the internet standards body under RFC 2606 specifically for documentation and testing. They are guaranteed never to belong to a real company or accept real mailboxes, so if your test system accidentally sends an email, it cannot land in anyone's inbox.
Could a generated record match a real person by accident?
A name might, because the lists use common UK names and a random pairing can coincide with somebody real. Nothing else will: the phone numbers, emails and full record combinations are synthetic, so no generated row describes an actual person or lets anyone contact one.
Is dummy data safer than testing with real customer data?
Much safer. Real customer records in a test database are still personal data under UK GDPR, with all the security, access and retention duties that brings, and a leaked staging server becomes a real breach. Synthetic records carry none of that risk because there is nobody to harm.
How is the CSV formatted?
The first line holds snake_case column headers, one row follows per record, and any value containing a comma, quote or line break is wrapped in double quotes with inner quotes doubled, per RFC 4180. Dates of birth use the ISO YYYY-MM-DD format, which spreadsheets and databases both import cleanly.