Best regex for email address pattern validation

The best all-around regex to find valid email addresses

Before we get ourselves to the bottom of the said rabbit hole, let's jump straight to the best regex for email validation just to save your time:

Source: https://stackoverflow.com/questions/201323/how-can-i-validate-an-email-address-using-a-regular-expression?page=2&tab=active#answer-14075810

You may simply copy-paste the above regular expression but please note that it's more than recommended to keep on reading. This is since as you'll find in the upcoming sections, there's more to validating user input email addresses through regular expressions than simply copying a code.

This somewhat complex regex validating email addresses

• allows Latin characters ("a" - "z" or "A" - "Z") within the email address.
• permits digits (0 - 9) in the email address.
• enforces domain part restrictions.
• allows hyphens (-) inside the domain as long as they don't lead or trail the domain.
• allows IP address literals surrounded with square brackets ([]) for the domain names.
• restricts sub-domains to a maximum length of 63 characters.
• applies local part restrictions.
• permits the set of special characters allowed by RFC 5322 ("!", "#", "$", "%", "&", "'", "*", "+", "-", "/", "=", "?", "^", "_", "`", "{", "|", "}", "~") to reside in the local part.
• lets local part comprise as double quotes housing one or more sequences of ASCII characters.
• doesn't allow trailing, leading, or consecutive periods anywhere within the email address.
  

While the above regular expression covers most of the email address-related rules and regulations, it does have some shortcomings:

• doesn't allow Unicode characters.
• doesn't check for the entire length of the email address to be less than or equal to 253 characters.
• ignores obsolete syntax-related rules.
  

Want to get a bit more practical? Refer to our email regex guide for a full list of code examples by language.

General user input email patterns and regular expressions

Before your company's corporate mail gets swarmed with SQL injection attacks or your personal emails get sent to the wrong recipients, let's get a brief idea of email addresses and regular expressions just so you'll know exactly what to look out for.

A general email address looks like this

According to the currently used Internet Message Format (IMF) named RFC 5322, a general email pattern takes this form: local-part@domain

The elements that make up this email pattern are:

• Local-part – a locally interpreted string constrained by a collection of rules the currently active IMF enforces. RFC 5322 lets the local-part conform to a dot-atom or a quoted string.
• "@" sign – symbol separating the local-part from the domain. An ASCII character of value 64 is used to represent this element.
• Domain – a string holding the name of the web service to which the email should be delivered. RFC 5322 asks the domain of valid email addresses to consist either of a dot-atom or a domain-literal within square brackets ([]).

What about regular expressions?

A regular expression — or its more commonly used term, a regex — is simply a search pattern defining what a particular string that wishes to match with it should and/or shouldn't have. 

Use cases of regular expressions

Regular expressions are widely used for string searching and string replacing tasks such as

• Validate email addresses. On web forms, this process often begins with simple client-side checks, like those provided by native HTML email validation, before more complex regex patterns are applied.
• Web scraping.
• Credit card number format validation.
• Validating password input string against complexity requirements.
• Removing unwanted characters from strings, e.g., punctuation, extra space.

For a detailed look into how different programming languages handle regular expressions, have a look at our email validation regex guide.

The basic format of a regular expression

Regular expressions comprise textual patterns holding

Metacharacters

A collection of 'characters and sequences of characters' reserved by regular expressions to represent specific patterns. 

For instance, a caret symbol (^) and a dollar symbol ($) would mean the start and end of a string consecutively. Similarly, a period (.) inside a regular expression would mean "any character".

Hence, a regular expression such as ^.$ would act as a case insensitive matching option matching with any single character like "D", "g", "5".

A simple googling would bring you cheatsheets holding these regular expression metacharacters you could easily refer to.

Regular characters

Usual characters that'd be matched for their literal value. 

Adding to the above regex, regular expressions like ^.ed$ will match with strings such as "bed", "fed", or "Ted".

RFC 5322 official standard regular expression to validate email addresses

The above regular expression conforms to the RFC 5322 standard and matches with basic email addresses.

Let's walk through each section of this regular expression, shall we?

• local-part matches with one or the other of two subsections:
• [-!#-'*+/-9=?A-Z^-~]+(\.[-!#-'*+/-9=?A-Z^-~]+)* – match with a dot-atom-text.
• "([]!#-[^-~ \t]|(\\[\t -~]))+" – match with a quoted-string within double-quotes. This regex subsection excludes whitespace-related rules RFC enforces for a quoted-string since they're irrelevant when validating emails.

Similarly, the domain matches with either one of two subsections:

• [-!#-'*+/-9=?A-Z^-~]+(\.[-!#-'*+/-9=?A-Z^-~]+)* – match with a dot-atom-text.
• \[[\t -Z^-~]*] – match a domain-literal; note that this regex subsection ignores whitespace-related rules RFC defines for domain-literals which are irrelevant when you need to match email addresses.
  

As for further limitations, notice that 

• its source informs the regular expression isn't "optimized for performance".
• this regular expression overlooks rules related to RFC's obsolete syntax.

Supplemental additions

A few more changes to the previous regular expression could improve its accuracy:

How about we explore the new additions and modifications added to the above regular expression?

• (25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(\.(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])){3} – match with IPv4-address-literals.
• IPv6:((((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){6}|::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){5}|[0-9A-Fa-f]{0,4}::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){4}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):)?(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){3}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,2}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){2}|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,3}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,4}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::)((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3})|(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(\.(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])){3})|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,5}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3})|(((0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}):){0,6}(0|[1-9A-Fa-f][0-9A-Fa-f]{0,3}))?::) – match with IPv6-address-literals.
• [0-9A-Za-z-]*[0-9A-Za-z]:[!-Z^-~]+ – match with general-address-literals.
• [0-9A-Za-z]([0-9A-Za-z-]{0,61}[0-9A-Za-z])? – enforce subdomains to have a maximum length of 63 characters.

Why regex might not be your best friend for validating email addresses

Time for the plot twist! Up until this point, we lay the groundwork of validating email addresses through regular expressions and explored the best regular expressions to do so. But, what if I told you that using regular expressions to validate email addresses is actually more hazardous than you might've imagined?

A hit on performance

With the RFC 5322 standard's complexities, a regular expression honoring all its rules & regulations may end up as one large expression requiring high CPU loads to process. Hence, these complex regex instances could end up lagging your company's servers, and what's worse? A hacker could exploit this and launch a ReDoS attack completely halting your web service.

An inconvenience to maintain

Assume you're currently using the most optimal and updated regular expression to validate email addresses. But, since a regular expression isn't some program you can add/remove some modules to/from, the moment IMF changes to a new standard you'd be back at square one, and you'd have to search for the new "best regex" once again.

What's better?

Due to the aforementioned drawbacks among others, it could be more appropriate to resort to an API to find valid email addresses. Just to help you out, here are the best email validation and verification APIs that currently exist on the market.

Conclusion

Because of its precise search pattern matching and compact nature, a regular expression can be your best bet to validate user input email addresses in most everyday scenarios. Having said that, in more cases than not, using an API to validate email addresses can be called a good alternative for the same purpose.

If you want a deeper dive into how specific programming languages and frameworks find valid email addresses, check out how the Python, Ruby, PHP programming languages and the jQuery framework face these e mail address verifications.

Indeed, we discussed all the essentials about regular expressions and how they may help your email address verification endeavors. But, let us end this article with a quite important guideline:

Always test your chosen regular expression on the website, app, server, etc., the location you'd be using it in instead of simply copy-pasting it so as to save yourself from matching invalid addresses and the heaps of terrible dilemma that'd follow.

Frequently Asked Questions

What is email address pattern validation?

Email address pattern validation is the process of checking whether an email address matches a defined structural format, typically using a regular expression (regex). It verifies that the address has a valid local part, an "@" symbol, and a properly formatted domain, but it does not confirm whether the address actually exists or can receive mail.

What regex pattern should I use to validate an email address?

For most use cases, a pattern that checks for a local part made of alphanumeric characters and common special characters, an "@" symbol, and a domain with a valid TLD is sufficient. A comprehensive RFC 5322-compliant pattern also supports IPv4/IPv6 literals, quoted local parts, and subdomain length limits (max 63 characters), but comes with higher maintenance overhead and performance costs.

What are the limitations of using regex for email validation?

Regex can only check format; it cannot verify that the mailbox exists, that the domain is live, or that the address will actually receive messages. Even a fully RFC 5322-compliant pattern has gaps: it typically ignores the 253-character total length limit, does not support Unicode characters, and can be vulnerable to ReDoS (Regular Expression Denial of Service) attacks if not carefully written.

How do I validate an email address in Python, Ruby, or PHP?

Each language has built-in regex libraries you can use to apply an email pattern: Python's re module, Ruby's built-in regex support, and PHP's preg_match or filter_var with FILTER_VALIDATE_EMAIL. The pattern logic is the same across languages; only the syntax for compiling and matching differs. Always test your chosen pattern against a wide range of valid and invalid addresses before deploying.

When should I use an email validation API instead of a regex?

Use an API when you need to go beyond format checking: for example, to verify that the domain has valid MX records, detect disposable addresses, or confirm deliverability. An API also removes the maintenance burden of keeping your regex up to date as email standards evolve. For high-volume or business-critical use cases, an API is generally the more reliable and scalable option.

How can I validate email addresses in jQuery or a browser-based form?

In a browser, you can use the HTML5 type="email" input attribute for basic pattern checking, or apply a custom regex via jQuery's validation plugin. Client-side validation improves user experience by catching obvious typos immediately, but it should always be paired with server-side validation; client-side checks can be bypassed and are not sufficient on their own.