Random Email Generator

Generate fake email addresses for testing and development.

Domain

Quantity

Style

About random email generation

All addresses are fictitious and generated entirely in your browser — no data is sent to any server. They are useful for seeding test databases, filling form fields in UI tests, or generating mock data for demos. Use a real domain like example.com (reserved by IANA for documentation) or your own test domain.

For fake user profiles, see the Fake Data Generator.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Producing addresses for a test fixture without touching real inboxes.
Generating input to exercise email validation and normalisation.
Filling a demo dataset with plausible-looking addresses.
Producing distinct addresses for a batch of test accounts.
Testing how a UI truncates a long address.

Frequently Asked Questions

Are these real addresses?: No, and that matters — sending to a randomly generated address risks reaching a real person's mailbox. For test data use the reserved domains example.com, example.org and example.net, defined by RFC 2606 precisely to never resolve.
Which domains are safe for testing?: RFC 2606 reserves .test, .example, .invalid and .localhost as TLDs, plus the example.com family. RFC 6761 reinforces this. Using a real-looking domain like mycompany.com in fixtures is how test mail escapes into production.
Why test with awkward addresses?: Because real ones break naive validators: plus-addressing (user+tag@), subdomains, long TLDs like .photography, quoted local parts, and internationalised addresses. A validator tested only on [email protected] rejects legitimate users.
Is the local part case-sensitive?: Technically yes per RFC 5321, though effectively every provider treats it case-insensitively. The domain is definitively case-insensitive. Deduplicate by lowercasing the domain; lowercasing the local part is conventional but not strictly correct.
Can I use these for signups?: No — they cannot receive mail, so any confirmation flow will fail. For manual testing you need a disposable inbox service or a mail catcher like MailHog that accepts everything locally.
Which characters are legal in the local part?: More than most validators allow — `+`, `.`, `-`, `_` and, when quoted, even spaces and `@`. Testing with a plus-addressed or dotted local part is how you find a form that rejects an address its owner genuinely uses.
Do plus addresses always work?: No. Gmail and many providers route `user+tag@` to `user@`, but it is a convention rather than a standard, and some providers and forms reject the character outright. That inconsistency is exactly why it is worth testing.
How long can an address be?: 64 characters for the local part and 254 for the whole address, per the SMTP standard. A `varchar(255)` column is the usual sizing, and a form limiting to 50 will reject real addresses.

Common errors and gotchas

Sending mail to a generated address, which may belong to a real person.
Using a real domain in generated addresses, which puts your test traffic on someone else's server.
Generating only simple addresses, so plus-addressing and unusual local parts go untested.
Assuming the addresses are deliverable, which they are not and should not be.
Letting generated addresses reach a production mailing list through a seed script.