Identity Generator
Runs locallyChoose your settings and select Generate identities. Records appear here and can be exported as CSV or JSON.
What this identity generator does
This tool builds a complete, internally consistent record for a fictional person. You choose a country, a gender preference, an age range, and how many records you need. The generator combines a first name and surname from that country’s name lists, pairs a real city with its correct region and postcode, and produces a synthetic street line, phone number, email address, date of birth, national ID, username, and password.
Every field is generated locally by JavaScript. There is no API call, no database write, and no analytics event containing the records. After the page has loaded, you can turn off your internet connection and the generator will keep working.
The output is intended for software testing, quality assurance, demos, database seeding, and privacy training. It is not a real identity and cannot be used to verify, impersonate, or contact a real person.
- 10 country profiles with local name lists, address formats, phone ranges, and ID labels.
- Seed-based reproducibility so a QA run can be repeated exactly.
- CSV and JSON export for spreadsheets, fixtures, and test scripts.
- Field toggles so you can omit national IDs, passwords, or blood type when they are not needed.
Why use synthetic identities instead of real data
Copying production data into a development or staging environment is one of the most common ways personal information leaks. A developer exports a customer table to reproduce a bug, the file ends up in a shared drive, and a breach notification follows. Synthetic records remove that risk entirely: if a test database is exposed, there is nobody to notify.
1. Privacy and PII regulations
GDPR, CCPA, and similar laws treat names, addresses, phone numbers, and government identifiers as personal data. Using real records in a test environment usually requires a lawful basis, a retention schedule, and security controls that are disproportionate for a temporary fixture. Synthetic data has none of those obligations because it does not relate to a living person.
2. No accidental contact
A test that triggers a welcome email, an SMS, or a phone call should never reach a real inbox or handset. This generator uses reserved email domains and fictional phone ranges, so automated jobs that escape the test environment have nowhere real to deliver to.
3. Repeatable tests
Random data makes failures hard to reproduce. With a seed, the same input produces the same records every time. Paste the seed into a bug report and another developer can regenerate the exact fixture you used.
4. Edge cases and localisation
Real test suites often use “John Smith” for every user, which hides layout and encoding bugs. Generating names with accents, hyphens, apostrophes, and non-Latin scripts exposes overflow, truncation, and database collation problems before users find them.
Why the IDs and phone numbers are deliberately invalid
Most identity generators try to make every field look as realistic as possible. That is the wrong default for sensitive identifiers. A generated Social Security number that happens to match a real person can cause serious harm when it is pasted into a ticket, a screenshot, or a public demo. This tool takes the opposite approach: sensitive fields are drawn from ranges that cannot belong to a living person.
| Field | Range used | Why it is safe |
|---|---|---|
| US SSN | 900–999 area series | The Social Security Administration has never issued area numbers in this range. |
| UK phone | 07700 900000–900999 | Ofcom reserves this block for drama and testing; calls are not connected to real subscribers. |
| US / Canada phone | 555-0100–555-0199 | The NANP reserves this exchange and line range for fictional use. |
| example.com, example.net, example.org | RFC 2606 reserves these domains; they cannot receive mail from the public internet. | |
| Other national IDs | All-zero or documented test patterns | Clearly invalid, so they fail validation instead of colliding with a real record. |
How each field is generated
| Field | Method | Example |
|---|---|---|
| Full name | Country-specific first and last name lists, filtered by gender preference | Amelia Clarke |
| Date of birth | Random date inside the age range you select, returned as ISO 8601 | 1989-04-17 |
| Street address | Random number plus a clearly synthetic street name | 482 Sample Avenue |
| City / region / postcode | Correctly paired real locations for the selected country | Austin, TX 78701 |
| Phone | Reserved fictional range for that country | +1 (512) 555-0142 |
| Name pattern plus an RFC 2606 reserved domain | [email protected] | |
| National ID | Country-specific invalid or test range | 912-34-5678 (US test SSN) |
| Username | ASCII slug of the name plus two digits | amelia.clarke42 |
| Password | 16 characters from crypto.getRandomValues, including upper, lower, digit, and symbol | K7#pQ2!mR9@vX4$z |
| Blood type | Random selection from the eight standard groups (optional) | O+ |
Common testing scenarios
Form validation
Generate 50 records and submit them through a registration form. Check that duplicate detection works, that long names do not break the layout, and that accented characters survive the round trip through your database and API.
Database seeding
Populate a development database with 100 users so you can test pagination, search, sorting, and admin filters. Because every record is synthetic, a staging dump that leaks contains nothing sensitive.
UI mockups and screenshots
Use generated names and addresses in design mockups instead of masking a real customer’s data. You get realistic-looking screenshots without a privacy review.
Localisation and encoding
Switch between country profiles to test diacritics (José, Müller, Chloé), non-Latin scripts (山田, 王伟), and different address lengths. This is where many forms and PDF templates fail.
Load and performance testing
Seed a load test with thousands of unique users so your test does not hammer the same record and produce misleading cache behaviour.
Privacy training and demos
Show a product demo with data that cannot be mistaken for a real customer. This is especially useful for sales demos and recorded walkthroughs.
How to use the generator
- Choose a country. This controls the name lists, address format, phone range, and national ID label.
- Set gender and age range. “Any” alternates between male and female name lists. The age range is inclusive.
- Add a seed if you need repeatability. Leave it blank for a fresh random dataset; the tool will show you the seed it used so you can reuse it later.
- Choose which fields to include. Turn off national ID or password if your test only needs names and contact details.
- Generate, then export. Use CSV for spreadsheets and SQL imports, or JSON for API fixtures and automated tests.
Tip: keep the seed with the exported file. It is the fastest way to reproduce a dataset when a test fails.
What this tool does not do
- It does not create real identities. Every record is fictional and every sensitive identifier is deliberately invalid.
- It is not a KYC or verification bypass. The output will fail identity checks, which is the intended behaviour.
- It does not generate credit card numbers. Card numbers have their own validation rules; use the separate credit card validator for Luhn testing.
- It does not send or receive email. Addresses use reserved domains that cannot receive mail.
- It is not a server API. Everything runs in the browser, so there is no endpoint to call from a backend job.
- Coverage is limited to ten countries. Address and ID formats for other countries are not included yet.
Frequently asked questions
Is the identity generator free?
Yes. There is no account, no email gate, and no daily limit. The generator runs in your browser, so there is no server cost to pass on to you.
Is the generated data real?
No. Names come from public name lists, addresses use real cities with synthetic street lines, and every sensitive identifier is drawn from a range that cannot belong to a living person. Treat the output as fictional test data.
Does the tool upload or store anything?
No. Generation happens in JavaScript on your device. There is no API call and no database write. You can disconnect from the internet after the page loads and the generator still works.
Why do the SSNs and phone numbers look invalid?
They are intentionally drawn from reserved ranges: the unissued US 900–999 SSN area, Ofcom’s UK drama numbers, and RFC 2606 email domains. This prevents a generated record from accidentally matching a real person.
Can I reproduce the same dataset?
Yes. Enter a seed before generating. The same seed and settings produce the same records, which is useful for repeatable QA runs and bug reports.
Can I export the results?
Yes. Export CSV for spreadsheets and database imports, or JSON for API fixtures and test scripts. You can also copy one record or the whole batch.
Which countries are supported?
Ten: United States, United Kingdom, Canada, Australia, India, Germany, France, Italy, Japan, and China. Each has its own name lists, address format, phone range, and ID label.
Is it legal to use fake identity data?
Using synthetic records for software testing, demos, and training is normal practice. Using them to impersonate someone, pass identity verification, obtain credit, or commit fraud is illegal in most jurisdictions. This tool is not a KYC bypass.
Can I use these records in production?
No. They are test fixtures. Production systems should contain real, consented user data, and generated passwords should never be reused for real accounts.
About this tool and how it is maintained
Editorial process and verification standards are documented in our editorial policy. Data-handling details are in the privacy policy.