What is the best regex for email validation?

For most use cases: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ — this covers standard emails with dots, hyphens, plus signs, and TLDs of 2+ characters. The RFC 5322 compliant regex is thousands of characters long and unnecessary for form validation. Keep it simple and verify with a confirmation email instead.

Does the simple email regex catch all valid emails?

No. It misses edge cases like quoted local parts ("user name"@domain.com), IP-address domains (user@[192.168.1.1]), and single-character TLDs. These represent less than 0.01% of real email addresses. For production, use a simple regex for client-side validation and verify the address by sending a confirmation email.

What regex pattern validates US phone numbers?

For flexible US numbers: ^\+?1?[-.\s]?$?\d{3}$?[-.\s]?\d{3}[-.\s]?\d{4}$ — this matches (555) 123-4567, 555-123-4567, 5551234567, +1 555 123 4567, and 1-555-123-4567. It handles parentheses, dashes, spaces, dots, and the optional country code.

How do I validate international phone numbers with regex?

International numbers vary too much for one regex. A reasonable pattern: ^\+[1-9]\d{6,14}$ matches E.164 format (+country code followed by 7-15 digits). For proper international validation, use a library like libphonenumber instead of regex — it handles country-specific rules, area codes, and formatting.

Should I use regex or a library for email validation?

Use both. Regex for instant client-side feedback (catches obvious typos like missing @ or .com). A library or server-side check for deeper validation (DNS lookup, disposable email detection). And always send a confirmation email — it is the only way to truly validate an email address exists and is owned by the user.

Why does my email regex reject valid addresses?

Common mistakes: not allowing plus signs (user+tag@gmail.com), not allowing dots in local part, requiring specific TLD lengths (.museum, .photography are valid), not allowing subdomains (user@mail.example.co.uk). Test your pattern against edge cases in a regex tester before deploying.

Can I test these patterns before using them in code?

Yes. Copy any pattern from this page, open the regex tester, paste the pattern, then paste sample email addresses or phone numbers as test text. You will see which strings match and which do not — before writing a single line of production code.

What regex flags should I use for email validation?

Use i (case-insensitive) so the pattern matches User@Example.COM. Do not use g (global) if you are validating a single input field — you want one match on the entire string, not multiple partial matches. Use ^ and $ anchors to ensure the entire string is a valid email, not just a substring.

Email & Phone Number Regex Patterns — Test & Validate Online

Last updated: April 20267 min readDeveloper Tools

You are writing a signup form and need an email regex that does not reject real users or accept garbage. Here are the patterns that work in production, with honest notes on what they miss and when to use something else.

Email Validation Regex Patterns

Pattern Name	Regex	Catches	Misses
Simple (recommended)	`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$`	99%+ of real emails	Quoted local parts, IP domains
Strict TLD	`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,63}$`	Same + caps TLD length	Same as simple
With subdomains	`^[a-zA-Z0-9._%+-]+@([a-zA-Z0-9-]+\\.)+[a-zA-Z]{2,}$`	[email protected]	Quoted local parts
Ultra-permissive	`^.+@.+\\..+$`	Everything with @ and a dot	Almost nothing — too loose

Use the simple pattern. It catches the real emails your users type. Do not use the RFC 5322 regex (it is 6,300+ characters long). No one has an email address that needs it. Send a confirmation email instead — that is the real validation.

Email Pattern Breakdown

Taking the recommended pattern apart:

^ — start of string (nothing before the email)
[a-zA-Z0-9._%+-]+ — local part: letters, digits, dots, underscores, percent, plus, hyphen (one or more)
@ — the literal @ symbol
[a-zA-Z0-9.-]+ — domain: letters, digits, dots, hyphens
\. — literal dot before TLD
[a-zA-Z]{2,} — TLD: 2 or more letters (.com, .uk, .museum, .photography)
$ — end of string (nothing after the email)

Test this pattern with your real user data before shipping it.

Phone Number Regex Patterns

Format	Regex	Example Matches
US flexible	`^\\+?1?[-.\\s]?\$?\\d{3}\$?[-.\\s]?\\d{3}[-.\\s]?\\d{4}$`	(555) 123-4567, 555-123-4567, +1 555 123 4567
US strict (10 digits)	`^\\d{3}-\\d{3}-\\d{4}$`	555-123-4567 only
US digits only	`^\\d{10}$`	5551234567
International E.164	`^\\+[1-9]\\d{6,14}$`	+14155551234, +442071234567
With extension	`^\\+?\\d[\\d\\s.-]{6,14}(\\s?(ext\|x)\\.?\\s?\\d{1,6})?$`	+1 555-123-4567 ext 890

Common Validation Mistakes

Blocking plus signs in emails — [email protected] is valid. Gmail, Outlook, and others support plus addressing for filtering. Your regex must allow + in the local part.
Requiring 3-letter TLDs — .co, .io, .ai are 2-letter TLDs. .photography is 11 letters. Use {2,} not {3}.
Hardcoding US phone format — if you have international users, \d{3}-\d{3}-\d{4} rejects every non-US number. Use the E.164 pattern or a phone library.
Not anchoring with ^ and $ — without anchors, \d{10} matches "call 5551234567 now" because 10 digits exist inside the string. Anchor the pattern to validate the entire input.
Trusting regex alone — [email protected] passes every email regex. Send a confirmation email. For phones, send an SMS code. Regex checks format, not existence.

Test Before You Ship

Copy any pattern above, open the Regex Tester, and paste it. Then paste these test strings to check edge cases:

Email edge cases: [email protected], [email protected], [email protected], [email protected], "spaces here"@domain.com
Phone edge cases: (555) 123-4567, +1-555-123-4567, 555.123.4567, +442071234567, 123 (too short)

If your pattern rejects a valid input or accepts an invalid one, adjust before deploying. Five minutes of testing saves hours of debugging user complaints.

Developer Tool Stack for Validation

Regex Tester — test validation patterns with live matching
JSON Formatter — validate and format API response data
Code Formatter — clean up validation code
Diff Checker — compare regex pattern versions

Test your email and phone regex patterns before they hit production.

Open Regex Tester

Format	Regex	Example Matches
US flexible	`^\\+?1?[-.\\s]?\\(?\\d{3}\\)?[-.\\s]?\\d{3}[-.\\s]?\\d{4}$`	(555) 123-4567, 555-123-4567, +1 555 123 4567
US strict (10 digits)	`^\\d{3}-\\d{3}-\\d{4}$`	555-123-4567 only
US digits only	`^\\d{10}$`	5551234567
International E.164	`^\\+[1-9]\\d{6,14}$`	+14155551234, +442071234567
With extension	`^\\+?\\d[\\d\\s.-]{6,14}(\\s?(ext\|x)\\.?\\s?\\d{1,6})?$`	+1 555-123-4567 ext 890

Email & Phone Number Regex Patterns — Test & Validate Online

Email Validation Regex Patterns

Email Pattern Breakdown

Phone Number Regex Patterns

Common Validation Mistakes

Test Before You Ship

Developer Tool Stack for Validation

Related Posts

Regex Tester Guide

Regex Cheat Sheet

Regex101 Alternatives

How to Test Regex