Create realistic-looking fake email addresses for testing and placeholder data, then download the generated output as a FAKEEMAIL file.
These are not real email addresses. Use for form testing only — sending mail to them may bounce or hit live users.
example.com, example.net, example.org, or anything under .test / .invalid / .localhost).example.com is the safest pick because IANA has reserved it for documentation since 1999 and it can never resolve to a real inbox.firstname.lastname123, firstinitial.lastname) using @faker-js/faker, lowercases everything, and strips characters outside [a-z0-9._-] so each address conforms to RFC 5321 dot-atom rules.Real automated tests and seed data shouldn't touch live mailboxes. A fake email generator produces strings that look like email addresses but, when paired with a reserved domain, can never reach a real human — eliminating the risk of pinging a stranger every time CI runs.
[email protected] passes browser regex, HTML5 type="email", and most server-side validators without ever leaving the test environment.users.email for staging needs to look real (unique local parts, plausible domains) without colliding with production users or triggering transactional email.[email protected] is the macOS convention.@example.com) means the mail server's DNS lookup fails before any bounce is recorded against your domain.[email protected] in a fixture is a real Gmail inbox owned by someone. Every dev who has ever shipped a bug knows the dread of CC'ing a stranger. Reserved domains make that impossible by design.The web conflates these, but for testing they behave very differently. A fake email is just a string with no inbox; a disposable email is a real inbox that auto-expires.
| Property | Fake Email (this tool) | Disposable Email (10minutemail, Mailinator) |
|---|---|---|
| Receives real mail? | No — string only | Yes, until it expires |
| Inbox UI? | None | Public or temporary web UI |
| Auto-expires? | N/A (no inbox) | Yes (10 min – 24 h typical) |
| Good for: verification links | No | Yes |
| Good for: load tests / seeds | Yes | No (rate-limited, public) |
| Privacy risk to real users | None (reserved domain) | Mailinator is public — anyone reads |
| Sender reputation impact | None (DNS fails fast) | Many ESPs block known disposable TLDs |
| Typical domains | example.com, *.test, *.invalid |
mailinator.com, 10minutemail.com |
For a real catch-all inbox you can query in CI (verification links, OTPs, password resets), see purpose-built services in the FAQ. The xconvert tool covers the string-only side.
| Zone | Purpose per IANA / IETF | Will it ever resolve? |
|---|---|---|
example.com |
Reserved second-level domain for documentation (RFC 2606 §3) | Resolves to IANA's placeholder page; no MX records for inbound mail |
example.net |
Same — reserved for documentation | Same |
example.org |
Same — reserved for documentation | Same |
.test |
Reserved TLD for "testing of current or new DNS related code" (RFC 2606 §2) | Never — must not be delegated |
.example |
Reserved TLD for documentation (RFC 2606 §2) | Never — must not be delegated |
.invalid |
Reserved TLD for "obviously invalid" addresses (RFC 2606 §2) | Never |
.localhost |
Reserved TLD that resolves to the loopback address (RFC 6761) | Only locally |
Pick any of these and you're guaranteed the address will never reach a real person. The dropdown's "Custom domain..." option lets you type any of them directly.
Yes for syntactic validation, no for deliverability. Most APIs apply RFC 5321/5322 format checks at the request layer — [email protected] passes those because the syntax is valid. Stripe's documentation in fact uses [email protected] as the canonical pattern for triggering location-based test scenarios. Where it fails: services that run an MX-record lookup or send a verification email (SendGrid signup confirmation, AWS SES sandbox verification, Mailchimp double opt-in) will bounce because example.com has no MX. For those flows, use a disposable inbox service instead.
The four TLDs reserved by RFC 2606 section 2 (.test, .example, .invalid, .localhost) plus the three second-level reservations in section 3 (example.com, example.net, example.org). IANA confirms these "may be used as illustrative examples in documents without prior coordination" and that they "are not available for registration or transfer." Anything under those zones is guaranteed never to resolve to a real mailbox.
Three risks. First, if your domain has a catch-all MX configured, that mail lands in someone's inbox — usually the postmaster, who will eventually file a ticket. Second, your production monitoring (bounce rates, complaint rates with AWS SES) starts logging noise from test traffic and you can lose sender reputation. Third, every developer who clones the repo runs the same fixture, so [email protected] ends up cc'd on hundreds of automated emails. Reserved domains have none of those problems because DNS resolution fails before any SMTP session opens.
A fake email (what this tool generates) is just a string — there's no inbox behind it, nothing to receive mail, no expiration because there's nothing to expire. A disposable email service like 10minutemail or Mailinator gives you a real short-lived inbox you can poll for verification codes. Use this tool when you need 500 unique addresses for seed data or load tests; use a disposable service when your test needs to actually receive a verification link. They solve different problems.
Then you need a catch-all inbox service. Common options: Mailtrap for staging-environment SMTP sandboxing, Mailosaur for QA-grade email + SMS verification testing with an API, MailSlurp for programmatically created throwaway inboxes in automation, Inbucket for self-hosted local email capture, and Ethereal Email (free) for previewing transactional templates. These are different tools — they give you a real inbox you can poll. The xconvert generator just gives you the address strings; combine the two if you need both bulk addresses and a real inbox.
Yes — only for real @gmail.com accounts. Google documents that "if someone accidentally adds dots to your address when emailing you, you'll still get that email," so [email protected], [email protected], and [email protected] all deliver to the same Gmail mailbox. Important caveat: this does not apply to Google Workspace custom domains (@yourcompany.com) — Google states "dots do change your address" on those. For fake-email generation against Gmail, this means dot-variant addresses you produce here would all collide if Gmail ever processed them, so prefer the example.com reserved domain for true uniqueness in test data.
Yes — copy the generated list, paste it as a JSON or CSV fixture, and read one address per test or virtual user. Because every address ends in a reserved domain by default, your scripts can run on production-adjacent environments without risking real email delivery. For testing the receipt side (verification clicks), pair this tool with Mailosaur or MailSlurp as covered above — the workflow most QA teams use is: generate 500 unique senders here, then have one Mailosaur server address handle inbound for assertion.
No — every click of "Regenerate" produces a fresh batch from @faker-js/faker's internal PRNG, which is reseeded per run. If your tests need deterministic addresses (e.g. snapshot tests), copy the output once and commit it as a fixture file rather than calling the generator in CI. The generator is designed for one-shot bulk seed data, not for runtime randomness inside a deterministic test.
Nowhere — the entire generator runs in your browser via @faker-js/faker. There's no upload, no API call, no logging. You can confirm by opening DevTools → Network and clicking "Regenerate"; you'll see zero outgoing requests. Need other unique-per-row test data? Combine the address list with a UUID Generator for primary keys or a Password Generator for fixture passwords — same client-side model.