Why is email regex unreliable?

The full email specification (RFC 5321) allows characters and formats most regex patterns do not cover. Use regex for basic sanity checks but always send a confirmation email to verify deliverability.

Should I allow plus-addressing in emails?

Yes. Addresses like user+tag@example.com are valid and widely used for filtering. Make sure your regex includes + in the allowed characters before the @ sign.

How do I test my regex against multiple inputs?

Enter each test email on a separate line in the test string area. The tester highlights matches and non-matches so you can verify each case at a glance.

Regex Pattern for Email Validation

Email validation regex is simultaneously one of the most commonly written patterns in software and one of the most commonly gotten wrong. The real email specification (RFC 5321 and RFC 5322) permits a staggering range of formats that almost no production regex handles correctly — including quoted local parts with spaces, comments, and IP address literals as the domain. The practical approach accepted by the industry is to use a "good enough" regex that rejects obvious garbage while accepting the vast majority of real-world addresses, then send a confirmation email to verify deliverability. The pattern in this example uses a character class to match the local part (the portion before @), requiring at least one valid character, followed by @ and a domain with at least one dot. The {2,} quantifier on the TLD segment ensures at least two characters, which rejects single-character TLDs while accepting modern long TLDs like .photography or .technology. Test cases in this example cover: a standard address ([email protected]), plus-addressing with a subdomain ([email protected] — the + and dot are valid), a bare username with no @ (invalid), a domain with no TLD (invalid), an address starting with @ (invalid), and a multi-level subdomain address ([email protected]). Plus-addressing ([email protected]) is widely used by developers for filtering email: you might register on a site as [email protected] to track which services sell your address. Always include + in your allowed character set or you'll frustrate this legitimate use case. Real-world scenarios: a registration form validates email on the client before submission, reducing server load from obviously invalid inputs; an e-commerce checkout pre-validates the email field before the user moves to the next step; a bulk email tool validates a CSV of addresses before attempting to send, skipping malformed entries. Tips and pitfalls: don't make your regex too strict. Blocking addresses because they contain valid characters you didn't anticipate is worse than accepting some slightly malformed strings. The regex is a UX convenience check, not a security measure — server-side validation and the confirmation email are the actual gates.

Example

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/

# Test cases (one per line):
[email protected]
[email protected]
invalid-email
missing@tld
@nodomain.com
[email protected]

[ open in Regex Tester → ]

FAQ

Why is email regex unreliable?: The full email specification (RFC 5321) allows characters and formats most regex patterns do not cover. Use regex for basic sanity checks but always send a confirmation email to verify deliverability.
Should I allow plus-addressing in emails?: Yes. Addresses like [email protected] are valid and widely used for filtering. Make sure your regex includes + in the allowed characters before the @ sign.
How do I test my regex against multiple inputs?: Enter each test email on a separate line in the test string area. The tester highlights matches and non-matches so you can verify each case at a glance.

Related Examples

Regex Pattern for URL Matching

URL matching regex is needed in a surprising variety of situations: extracting l...

Regex Pattern for Phone Numbers

Phone number validation is notoriously difficult with regex because no single pa...

Regex Pattern for Password Strength

Password strength validation with regex relies on a powerful but often misunders...