Test identity generator

What this is for

Developers and QA engineers walking through registration flows need plausible values in every field — not a real colleague's name, not a personal address that will end up in a staging database, not a phone number that will receive test OTPs indefinitely. This tool generates synthetic names, usernames, cities, and birth years client-side, so form fields look human-shaped without belonging to any real person.

Pair it with a Thirtel inbox when the form requires email verification — the inbox receives real mail and expires after thirty minutes. Pair it with the password generator when the form requires a credential. Together the three tools cover the complete signup flow: email, password, and profile fields.

What you get

Each regenerate produces a synthetic full name, a username string, a city label, and a birth year. The data is drawn from small curated lists — ten first names, ten last names, eight cities. Enough to look plausible to a form without attempting to simulate real demographic distributions or guarantee uniqueness across runs.

All generation runs in your browser using Math.random(). Nothing is sent to Thirtel's servers. There is no account, no log, no stored profile. The values exist only in your browser tab until you close it or regenerate.

For single-flow manual walkthroughs, this is enough. For bulk test data, automated fixture generation, or load testing, use a purpose-built library — faker.js in JavaScript or Python's Faker package both generate large seeded datasets with more field variety and reproducible output.

Why real data is the wrong input for QA forms

Using a real colleague's name or a real home address in test environments creates three risks:

• Persistence. Staging databases are not always cleaned. If a snapshot gets exported for debugging, shared with a vendor, or committed to version control, real personal data travels with it. GDPR and similar regulations treat this as a breach risk regardless of intent.
• Unintended contact. Real phone numbers in fixtures receive test SMS messages every time the suite runs. A real person's inbox receives test verification emails they did not request.
• Weaker controls. Test environments typically have looser access controls than production. Populating them with real personal data creates an exposure surface that synthetic data eliminates entirely.

Synthetic data has no real subject to harm if it leaks. That is the point.

What synthetic data reveals about your forms

Running deliberate synthetic inputs through your registration flow surfaces validation bugs that are otherwise invisible in normal use.

Name encoding: if your test set includes names with apostrophes (O'Brien), hyphens, or non-ASCII characters (Nguyễn), you quickly find forms that truncate or reject them silently. These are real names that real users have, and finding the rejection in testing is far better than in production. Field length boundaries: generating a name at the maximum declared length exposes truncation behavior — a VARCHAR(30) column that silently truncates is a data integrity bug. Date edge cases: a birth date exactly at the age gate tests your own date arithmetic. Address format: different formats expose parsing inconsistencies. Country selection: synthetic addresses from different countries test whether conditional fields render correctly.

Synthetic data is the right input precisely because it can be crafted to hit specific edge cases on demand, without involving real people.

Hard limits — read this

• Do not use generated identities to deceive people, commit fraud, launder access, or bypass lawful identity verification.
• Do not present synthetic data as a real person to banks, governments, employers, or platforms that require verified identity.
• Do not use it to claim trials, promotions, or platform access you have already used — that violates terms of service and is fraud.
• Do use it for staging environments, demo walkthroughs, UX testing, and throwaway product evaluations.

"I was only testing" is not a defense for misuse. Identity fraud on online platforms has been prosecuted under computer fraud statutes in multiple jurisdictions. Acceptable use is defined in the Terms.

Where Thirtel's tool fits in the QA flow

Registration forms sit at the front of most applications. Before a user can do anything meaningful, they go through: email → password → profile fields → verification. Thirtel's three tools map to each step without requiring any server-side setup.

Open a Thirtel inbox for the email step. Generate a password for the credential step. Generate a test identity for the profile step. Receive the verification mail in the inbox, click or copy the code, and complete registration. The inbox expires after thirty minutes and the credentials become meaningless. No real personal data was used at any point.

The full QA workflow with notes on what each step validates: fake identity for signups.