Regex is practical for checking email addresses against a clearly limited input policy, such as the one used by HTML email forms. It is not a universal parser for every address form allowed in message headers, and a matching string does not prove that a mailbox exists or that a person can access it. Choose the tool according to the job: a form check, message parsing, or mailbox confirmation.
What regex can—and cannot—validate
A regular expression can determine whether a string fits the syntax rules encoded in that expression. That makes it useful for quick feedback on a form field, provided the application intentionally accepts that particular set of addresses.
It cannot establish that the address is deliverable, that a mailbox exists, or that the user controls the mailbox. Those require interaction with the mail system or, when user access matters, a confirmation email.
Why there is no universal “RFC-compliant email regex”
RFC 5322 defines syntax for Internet message headers, not a single convenient policy for ordinary signup forms. Its address forms include constructs such as quoted strings, comments, and domain literals that many web forms do not intend to accept. Conversely, its rules are not simply equivalent to the familiar address shape most users type into a form.
#1 Best Overall
The WHATWG HTML Standard deliberately defines a more practical grammar for an email input. It describes the departure from RFC 5322 as a “willful violation,” explaining that RFC 5322 is, for this form use, too strict in some places, too vague in others, and too permissive of forms unfamiliar to most users. The practical point is that standards serve different purposes: a form policy need not be a full message-header parser.
Use the HTML email grammar when it matches your form policy
For a browser form that intends to follow HTML’s email input definition, the standard provides this JavaScript- and Perl-compatible pattern:
Rank #2
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$This pattern implements the HTML form grammar; it does not accept every address form expressible in RFC 5322 and does not verify mailbox existence. If a form needs comma-separated addresses, HTML also defines list behavior for an email input used with its multiple attribute. See the HTML input element definition for the element’s behavior.
Choose the right approach for the job
| Approach | Appropriate use | What to consider |
|---|---|---|
Native HTML input type="email" |
Basic browser-side feedback using HTML’s defined form grammar. | Whether its accepted syntax fits the product’s policy, whether multiple addresses are needed, and that browser feedback is not mailbox verification. WHATWG HTML Standard. |
| Custom regex | Enforcing a clearly documented, application-specific address shape. | False rejection risk, readability and maintenance, matching client/server behavior, and whether internationalized addresses are supported. WHATWG discussion of internationalized email validation. |
| Standards-aware parser | Processing structured message addresses or broader message syntax. | Grammar coverage, error handling, robustness, and preservation of the address forms the application needs. RFC 5322; RFC 5321. |
| Confirmation email | Checking that the user can access the mailbox. | Plan for user friction, expiry and retry behavior, and account-security needs. Syntax matching alone cannot establish access. WHATWG HTML input element definition. |
Keep form validation separate from message parsing
If an application processes only a familiar address in a single form field, a deliberately limited regex or native HTML validation may be enough. If input can contain display names, comments, quoted forms, or other message-address structures, use parsing logic suited to the relevant message grammar. A simple form regex should not be presented as handling all RFC 5322 address syntax.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOn the server, keep acceptance policy consistent with the interface, but do not assume that copying a browser regex turns it into a general-purpose parser. Decide first whether the application accepts familiar form addresses, broader message-header syntax, or internationalized addresses.
Make an explicit decision about internationalized addresses
Do not assume that a pattern based on the HTML form grammar covers every internationalized email address. The HTML definition and discussion of internationalized email do not make all cases interchangeable; Unicode local-parts and domains need an explicit support decision. Check behavior across the systems the application serves before promising support. The WHATWG standards discussion documents this as an area requiring care.
Rank #4
Also avoid silently rewriting a user’s local-part to make it fit a preferred pattern. RFC 5321 notes that quoted local-parts and case-sensitive local-parts can create interoperability problems, but that is context for setting a policy—not permission to alter the address without the user’s knowledge.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify mailbox access with a confirmation flow
When an application needs confidence that a user can receive mail at an address, send a confirmation message and require the user to complete the confirmation. A regex answers only whether the entered string matches the selected syntax rules; it does not query the recipient’s mail system or prove control of the mailbox.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
