Stop writing regex from scratch every time. This guide gives you battle-tested, copy-paste-ready regex patterns for the most common validation tasks: email addresses, phone numbers, URLs, IP addresses, credit card formats, dates, passwords, and usernames. Every pattern includes an explanation, edge-case notes, and code examples in JavaScript and Python.
Test any pattern live in our Regex Tester ->
How to Use These Patterns
Each pattern below is shown inside a code block. Copy the raw pattern string directly into your code. In JavaScript, wrap it in forward slashes /pattern/ or pass it to new RegExp(). In Python, use a raw string r"pattern" with re.match() or re.fullmatch(). Always test against both valid and invalid inputs before deploying to production.
// JavaScript quick start
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
if (emailRegex.test(userInput)) {
console.log('Valid email');
}# Python quick start
import re
email_pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
if re.match(email_pattern, user_input):
print('Valid email')Email Validation
Email validation is the most common regex use case. There is no single regex that handles 100% of RFC 5322, but the patterns below cover the vast majority of real-world addresses.
Basic Email Pattern
Good enough for most web forms. Catches obvious typos without being overly strict.
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$Matches: user@example.com, john.doe+tag@sub.domain.org. Does not match: user@.com, @example.com, user@com.
RFC 5322 Compliant (Simplified)
A more thorough pattern that handles quoted local parts and longer TLDs. Still not 100% RFC-compliant (a true RFC 5322 regex is over 6,000 characters), but covers edge cases that the basic pattern misses.
^(?:[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$Common Domains Only
When you want to restrict to well-known providers (e.g., for consumer sign-up forms).
^[a-zA-Z0-9._%+-]+@(gmail|yahoo|outlook|hotmail|icloud|protonmail)\.[a-z]{2,}$Phone Number Validation
Phone number formats vary widely by country. Use these patterns as a starting point and adjust for your target locale.
US Phone Number
Matches common US formats with or without country code.
^(\+1[-\s.]?)?\(?[2-9]\d{2}\)?[-\s.]?\d{3}[-\s.]?\d{4}$Matches: +1 (555) 123-4567, 555-123-4567, 5551234567, +1.555.123.4567.
International Phone Number
A general pattern that allows country codes and various separators.
^\+?[1-9]\d{0,2}[-\s.]?\(?\d{1,4}\)?[-\s.]?\d{1,4}[-\s.]?\d{1,9}$E.164 Format (Strict)
The international standard for phone numbers. Used by Twilio, Stripe, and most APIs.
^\+[1-9]\d{1,14}$Matches: +14155552671, +442071234567. Maximum 15 digits total (including country code).
URL Validation
URL validation can be as simple or complex as needed. Choose the pattern that fits your requirements.
HTTP/HTTPS URL
Requires the http or https protocol prefix.
^https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)$URL With or Without Protocol
Matches URLs that may omit http:// or https://.
^(https?:\/\/)?([\da-z.-]+)\.([a-z.]{2,6})([\/\w .-]*)*\/?$Localhost URL
For development environments -- matches localhost with optional port and path.
^https?:\/\/(localhost|127\.0\.0\.1)(:\d{1,5})?(\/[^\s]*)?$Matches: http://localhost:3000/api, https://127.0.0.1:8080.
IP Address Validation
IP address validation requires careful range checking for each octet (IPv4) or group (IPv6).
IPv4 Address
Validates each octet is between 0 and 255.
^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.){3}(25[0-5]|(2[0-4]|1\d|[1-9]|)\d)$Matches: 192.168.1.1, 10.0.0.255. Rejects: 256.1.1.1, 192.168.1.
IPv6 Address (Simplified)
A simplified pattern for standard IPv6 notation. Full IPv6 validation (with :: shorthand) is extremely complex.
^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$IPv6 Address (Full with :: Shorthand)
Handles the :: zero-compression notation used in most real-world IPv6 addresses.
^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:))$IP Address with Port
IPv4 address followed by an optional port number (1-65535).
^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.){3}(25[0-5]|(2[0-4]|1\d|[1-9]|)\d)(:(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|[1-5]\d{4}|[1-9]\d{0,3}))?$Credit Card Number Patterns
Important: These patterns validate the format only (correct number of digits and prefix). They do NOT verify that a card number is real. Always use the Luhn algorithm for checksum validation in addition to regex.
Visa
^4[0-9]{12}(?:[0-9]{3})?$Starts with 4. Either 13 or 16 digits.
MasterCard
^5[1-5][0-9]{14}$|^2(?:2(?:2[1-9]|[3-9]\d)|[3-6]\d\d|7(?:[01]\d|20))[0-9]{12}$Starts with 51-55 or 2221-2720. Always 16 digits.
American Express
^3[47][0-9]{13}$Starts with 34 or 37. Always 15 digits.
Any Major Card (Combined)
^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|6(?:011|5[0-9]{2})[0-9]{12})$Covers Visa, MasterCard, AMEX, Diners Club, and Discover.
Date Format Patterns
These patterns validate the format of dates. For actual date validity (e.g., February 30), you should also validate with a date library.
YYYY-MM-DD (ISO 8601)
^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$Matches: 2026-01-15, 2026-12-31. Rejects: 2026-13-01, 2026-00-10.
MM/DD/YYYY
^(0[1-9]|1[0-2])\/(0[1-9]|[12]\d|3[01])\/\d{4}$DD.MM.YYYY
^(0[1-9]|[12]\d|3[01])\.(0[1-9]|1[0-2])\.\d{4}$Common in Germany, Switzerland, and other European countries.
Password Strength Validation
Use lookaheads to enforce multiple requirements in a single pattern. Adjust the minimum length and character requirements to match your security policy.
Strong Password (Min 8 chars, uppercase, lowercase, digit, special)
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$Requires at least: 1 lowercase, 1 uppercase, 1 digit, 1 special character from @$!%*?&, and minimum 8 characters total.
Medium Password (Min 6 chars, letter + digit)
^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{6,}$Custom Length Range (8-64 chars, all requirements)
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^\w\s]).{8,64}$The [^\w\s] class matches any special character (broader than a specific list).
Username Validation
Username patterns enforce a consistent format for user identifiers.
Alphanumeric + Underscore (3-16 chars)
^[a-zA-Z0-9_]{3,16}$Must Start with a Letter
^[a-zA-Z][a-zA-Z0-9_]{2,15}$Allow Dots and Hyphens (No Consecutive)
^[a-zA-Z0-9](?:[a-zA-Z0-9._-]*[a-zA-Z0-9])?$Must start and end with alphanumeric. No consecutive dots/hyphens. Similar to GitHub username rules.
Comparison Table: All Patterns at a Glance
Use this quick-reference table to find the right pattern for your use case.
| Use Case | Pattern | Notes |
|---|---|---|
| Email (basic) | ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ | Most web forms |
| Phone (US) | ^(\+1[-\s.]?)?\(?[2-9]\d{2}\)?[-\s.]?\d{3}[-\s.]?\d{4}$ | Multiple formats |
| Phone (E.164) | ^\+[1-9]\d{1,14}$ | API standard |
| URL (HTTP/S) | ^https?:\/\/[^\s]+$ | Quick check |
| IPv4 | ^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.){3}(25[0-5]|(2[0-4]|1\d|[1-9]|)\d)$ | 0-255 per octet |
| IPv6 (simple) | ^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$ | No :: shorthand |
| Visa | ^4[0-9]{12}(?:[0-9]{3})?$ | 13 or 16 digits |
| MasterCard | ^5[1-5][0-9]{14}$ | 16 digits |
| AMEX | ^3[47][0-9]{13}$ | 15 digits |
| Date (ISO) | ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ | YYYY-MM-DD |
| Date (US) | ^(0[1-9]|1[0-2])\/(0[1-9]|[12]\d|3[01])\/\d{4}$ | MM/DD/YYYY |
| Date (EU) | ^(0[1-9]|[12]\d|3[01])\.(0[1-9]|1[0-2])\.\d{4}$ | DD.MM.YYYY |
| Strong Password | ^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&]).{8,}$ | All requirements |
| Username | ^[a-zA-Z][a-zA-Z0-9_]{2,15}$ | Letter start, 3-16 chars |
Testing Your Regex
Always test regex patterns against both valid and invalid inputs before using them in production.
JavaScript Testing
// Method 1: RegExp.test() - returns boolean
const pattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
console.log(pattern.test('user@example.com')); // true
console.log(pattern.test('invalid@')); // false
// Method 2: String.match() - returns match array or null
const result = 'user@example.com'.match(pattern);
if (result) {
console.log('Matched:', result[0]);
}
// Method 3: String.matchAll() - for multiple matches with /g flag
const text = 'Contact us at info@test.com or help@test.com';
const emailPattern = /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g;
for (const m of text.matchAll(emailPattern)) {
console.log('Found:', m[0]);
}Python Testing
import re
# Method 1: re.match() - match at start of string
pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
result = re.match(pattern, 'user@example.com')
print(bool(result)) # True
# Method 2: re.fullmatch() - match entire string (Python 3.4+)
result = re.fullmatch(pattern, 'user@example.com')
print(bool(result)) # True
# Method 3: re.findall() - find all matches
text = 'Contact us at info@test.com or help@test.com'
emails = re.findall(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', text)
print(emails) # ['info@test.com', 'help@test.com']
# Method 4: Compiled pattern (best for repeated use)
email_re = re.compile(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$')
for addr in ['valid@test.com', 'bad@', 'ok@domain.org']:
print(f'{addr}: {bool(email_re.match(addr))}')Online Testing Tools
For interactive, visual regex testing, use our Regex Tester tool. You can also use sites like regex101.com or regexr.com for detailed breakdowns. Our tool supports JavaScript regex syntax with real-time highlighting.
Test any pattern live in our Regex Tester ->
Frequently Asked Questions
Should I use regex for email validation?
Regex is a great first-pass filter for email validation on the client side. It catches obvious typos (missing @, no domain, etc.) before the form is submitted. However, the only way to truly validate an email is to send a confirmation message to it. Use a basic regex pattern for UX, and verification emails for correctness.
Why are there so many different email regex patterns?
The email specification (RFC 5322) is extremely permissive -- it allows quoted strings, comments, IP address domains, and unusual characters. A fully compliant regex would be thousands of characters long and impractical. Most developers use a simplified pattern that covers 99.9% of real-world addresses. Choose your pattern based on how strict you need to be.
Can regex validate that a phone number actually exists?
No. Regex can only validate the format (correct number of digits, valid country code prefix, proper separators). It cannot verify that a number is assigned to a real line. For production phone validation, use a library like libphonenumber (Google) which has per-country rules and carrier validation.
How do I validate an IPv6 address with :: shorthand?
IPv6 with :: shorthand (zero compression) is notoriously difficult to validate with regex because the :: can appear anywhere and replaces one or more groups of zeros. The full pattern in this guide handles most cases. For production systems, consider using your language built-in IP parsing (e.g., Python ipaddress module, Node.js net.isIP()) instead of regex.
Is it safe to use regex for password strength validation?
Yes, regex with lookaheads is an efficient way to enforce password complexity rules (minimum length, required character types). However, password strength is about more than character diversity -- consider also checking against breached password databases (like HaveIBeenPwned) and using entropy-based scoring. Regex handles format rules; pair it with additional security checks.