Visual regex workbench
Build, test, explain and master regex with visual tools, guides, examples and a growing regex library.
Regex guide
Email validation is one of the most common regex use cases, but also one of the easiest to overcomplicate. This guide explains a practical email regex and when you should avoid trying to match every theoretical address.
Validates the basic structure of an email address.
^[^\s@]+@[^\s@]+\.[^\s@]+$alice@example.comjohn@test.orgA practical email validation pattern suitable for many web forms.
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$alice@example.comjohn.doe+shop@test.co.ukMatches email addresses using one or more subdomains.
^[^\s@]+@(?:[A-Za-z0-9-]+\.)+[A-Za-z]{2,}$alice@mail.example.comjohn@example.co.ukAccepts only Gmail addresses.
^[A-Za-z0-9._%+-]+@gmail\.com$alice@gmail.combob@gmail.comRestricts addresses to a single company domain.
^[A-Za-z0-9._%+-]+@company\.com$alice@company.comsales@company.comExtracts email addresses from text.
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}alice@example.combob@test.orgValidates a comma-separated list of email addresses.
^\s*[^\s@]+@[^\s@]+\.[^\s@]+(?:\s*,\s*[^\s@]+@[^\s@]+\.[^\s@]+)*\s*$alice@example.com, bob@test.orgAccepts email aliases using the plus sign.
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$john+shop@example.comalice+newsletter@gmail.comExtracts only the domain part after the @ symbol.
(?<=@)[A-Za-z0-9.-]+\.[A-Za-z]{2,}example.commail.company.orgExtracts the local part before the @ symbol.
^[^\s@]+(?=@)alicejohn.doeAccepts only email addresses ending with a specific top-level domain.
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.org$team@example.orgsupport@test.orgAccepts email addresses that do not belong to common free email providers.
^[A-Za-z0-9._%+-]+@(?!gmail\.com$|yahoo\.com$|hotmail\.com$|outlook\.com$)[A-Za-z0-9.-]+\.[A-Za-z]{2,}$alice@company.comsales@example.orgExtracts every email address found in a text.
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}sales@example.comhelp@test.orgceo@company.comFinds email addresses before replacing them with hidden values.
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}alice@example.combob@test.orgRejects email aliases containing the plus sign.
^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$alice@example.comRestricts email addresses to a predefined list of top-level domains.
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.(?:com|org|net)$alice@example.combob@test.orgEmail addresses look simple, but the official syntax is much more flexible than most people expect.
In real applications, a practical regex usually checks the common structure instead of trying to implement every possible RFC-valid address.
The goal is usually to catch obvious mistakes, not to prove that an address exists or can receive mail.
Fully RFC-compliant email regexes are often extremely long, difficult to read and hard to maintain.
For most forms, a practical regex combined with email confirmation is safer and easier to understand.
Use strict RFC validation only when your application specifically needs to accept every valid edge case.
An email regex can check for a local part, an @ symbol, a domain name and a top-level domain.
It can also restrict characters, require a minimum TLD length or reject whitespace.
However, it cannot confirm DNS records, mailbox existence or whether the address belongs to the user.
Many email providers support aliases such as john+shop@example.com.
Rejecting the plus sign can block valid users, especially on Gmail and developer-oriented services.
Unless you have a specific reason to forbid aliases, your regex should usually allow plus addressing.
Modern email systems can support internationalized domain names and, in some contexts, non-ASCII local parts.
Many simple email regexes intentionally focus on ASCII-only addresses because they are easier to support consistently.
If your application targets international users, test Unicode behavior carefully and consider using dedicated email validation libraries.
The most reliable way to verify an email address is usually to send a confirmation message.
A regex can reduce typos, but only confirmation proves that the user can access the mailbox.
For account creation, password reset and sensitive workflows, email confirmation is more important than making the regex stricter.
There is no single "best" email regex. The right choice depends on your application and the level of validation you need.
For most web forms, a practical regex that checks the general structure is sufficient when combined with email confirmation.
No. The official email specification allows many uncommon formats that are rarely used in practice.
Most applications intentionally use a simpler regex because it is easier to maintain and provides a better user experience.
No. A regex can only validate the format of an address.
To verify that an email really exists, you need confirmation emails or dedicated verification services.
Usually yes. Many providers such as Gmail support addresses like john+shop@gmail.com.
Rejecting them may prevent legitimate users from registering.
Client-side validation improves the user experience by catching typing mistakes immediately.
Server-side validation remains essential because client-side checks can always be bypassed.
Many simple regexes intentionally reject uncommon but technically valid email formats.
Review the assumptions made by your pattern and test it with realistic examples before deploying it.
An email regex can check the general shape of an address, but it cannot confirm that the mailbox exists or can receive messages.
Use regex for basic format validation, then rely on confirmation emails or server-side checks when real deliverability matters.
Read the complete guide →Email patterns should be tested with simple addresses, subdomains, plus signs, invalid domains and malformed input.
Testing both accepted and rejected examples helps avoid overly strict or overly permissive validation.
Read the complete guide →Email validation works best when regex is combined with normalization, clear error messages and server-side verification.
Read the complete guide →Email regexes often become too strict, too permissive or unnecessarily complex.
Common mistakes include trying to be fully RFC-compliant, forgetting edge cases or relying on regex as the only validation layer.
Read the complete guide →Email regexes are built almost entirely from character classes such as [A-Za-z0-9], \w and custom character sets.
Understanding these building blocks makes email patterns much easier to read and adapt.
Read the complete guide →Email validation also relies on quantifiers to define minimum lengths, optional characters and repeated sections.
Mastering quantifiers helps you understand why common email regexes are written the way they are.
Read the complete guide →