Email Address
Practical pattern that catches the email addresses you actually encounter without trying to implement full RFC 5322.
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}Common Regex Patterns
A curated library of practical regex patterns for everyday validation and extraction tasks — email, URL, IP addresses, phone numbers, dates, UUIDs, hex colors, credit cards, semver, and more. Each pattern is annotated with the cases it matches and the trade-offs it makes, so you can pick the right one without rereading the RFC.
HTTP/HTTPS URL
Loose pattern that finds candidate URLs in text. Pair with a real URL parser for structural validation.
https?:\/\/[a-zA-Z0-9.-]+(?::\d+)?(?:\/[^\s]*)?Domain Name (FQDN)
Matches fully-qualified domain names with one or more labels and a TLD of at least two letters.
(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}IPv4 Address (lenient)
Quick dotted-quad match. Allows octets up to 999 — fast for extraction, not for validation.
\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\bIPv4 Address (strict, 0–255)
Validates each octet falls in the legal 0–255 range.
\b(?:25[0-5]|2[0-4]\d|[01]?\d\d?)(?:\.(?:25[0-5]|2[0-4]\d|[01]?\d\d?)){3}\bIPv6 Address
Matches full and compressed IPv6 forms including :: and IPv4-mapped variants.
(?:(?:[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}:){0,6}[0-9a-fA-F]{1,4}|(?:[0-9a-fA-F]{1,4}:){1,6}(?::[0-9a-fA-F]{1,4}){1,1}|(?:[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})MAC Address
Matches MAC addresses with either colons or hyphens as separators.
(?:[0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}US Phone Number
Tolerant US phone matcher accepting country code, parentheses, dashes, dots, and spaces.
(?:\+?1[-.\s]?)?\(?(\d{3})\)?[-.\s]?(\d{3})[-.\s]?(\d{4})International Phone (E.164-style)
Matches numbers in E.164 international format with optional plus and 7–15 digits.
\+?[1-9]\d{1,14}US ZIP Code
5-digit ZIP code with optional ZIP+4 extension.
\b\d{5}(?:-\d{4})?\bUK Postcode
Royal Mail format. Letters case-insensitive; the central space is optional.
\b[A-Z]{1,2}\d[A-Z\d]?\s*\d[A-Z]{2}\bCanadian Postal Code
Canadian format A1A 1A1, with optional space.
\b[ABCEGHJ-NPRSTVXY]\d[A-Z]\s?\d[A-Z]\d\bUUID / GUID
Matches any RFC 4122 UUID (any version) in canonical hyphenated form.
\b[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-7][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}\bUsername
Standard username rules: 3–20 characters, letters, digits, and underscore, must start with a letter.
^[a-zA-Z][a-zA-Z0-9_]{2,19}$URL Slug
Lowercase letters, digits, and hyphens, no leading/trailing hyphen.
^[a-z0-9]+(?:-[a-z0-9]+)*$Strong Password (8+, mixed case, digit, symbol)
Demands at least 8 characters with at least one lowercase, one uppercase, one digit, and one symbol. Uses lookahead.
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*]).{8,}$Credit Card (major brands)
Detects Visa, MasterCard, American Express, Discover, JCB, and Diners Club by prefix and length.
(?:4\d{12}(?:\d{3})?|(?:5[1-5]\d{2}|2[2-7]\d{2})\d{12}|3[47]\d{13}|6(?:011|5\d{2})\d{12}|(?:2131|1800|35\d{3})\d{11}|3(?:0[0-5]|[68]\d)\d{11})Hex Color (3, 6, or 8 digit)
CSS-style hex colors with optional alpha channel.
#(?:[0-9a-fA-F]{3,4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})\bRGB / RGBA Color
CSS rgb() and rgba() function calls with optional alpha.
rgba?\(\s*\d{1,3}\s*,\s*\d{1,3}\s*,\s*\d{1,3}\s*(?:,\s*(?:0|1|0?\.\d+))?\s*\)ISO Date (YYYY-MM-DD)
ISO 8601 calendar date with strict month and day ranges.
\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])ISO 8601 Datetime
Full datetime with optional milliseconds and timezone offset (or Z for UTC).
\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])T(?:[01]\d|2[0-3]):[0-5]\d:[0-5]\d(?:\.\d+)?(?:Z|[+-](?:[01]\d|2[0-3]):[0-5]\d)Time (24-hour)
24-hour HH:MM with optional seconds.
(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d)?Integer (signed)
Whole number with optional sign. No leading zeros.
-?(?:0|[1-9]\d*)Decimal Number
Signed integer or decimal with optional fractional part.
-?\d+(?:\.\d+)?Scientific Notation
Numbers in scientific (E-notation) form.
-?\d+(?:\.\d+)?[eE][+-]?\d+Hexadecimal Number
Hex literal with 0x prefix. Convert with the base converter.
0[xX][0-9a-fA-F]+Semantic Version
SemVer 2.0.0 — major.minor.patch with optional pre-release and build metadata.
(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?HTML Tag
Matches an opening, closing, or self-closing HTML tag with attributes.
<\/?[a-zA-Z][a-zA-Z0-9-]*(?:\s+[a-zA-Z][a-zA-Z0-9-]*(?:\s*=\s*(?:"[^"]*"|'[^']*'|[^\s>]+))?)*\s*\/?>Markdown Link
Inline Markdown link [text](url) with optional title.
\[([^\]]+)\]\(([^\s)]+?)(?:\s+"([^"]+)")?\)Leading / Trailing Whitespace
Match whitespace at the start or end of a string. Replace with empty for trim.
^\s+|\s+$File Extension
Captures the trailing extension of a filename (after the last dot).
\.([a-zA-Z0-9]+)$Hashtag
Matches a hashtag with letters, digits, and underscores after the #.
(?:^|\s)#([a-zA-Z][a-zA-Z0-9_]*)Twitter / X Handle
Matches @-handle: 1–15 alphanumerics or underscores.
(?:^|\s)@([A-Za-z0-9_]{1,15})\bJWT (JSON Web Token)
Three Base64URL segments joined by dots.
[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+How to Use This Tool
- Search or filter for the pattern type you need —
email,ipv4,semver,color, etc. - Read the description and Note on the pattern. Many patterns make practical trade-offs (loose vs strict, RFC-compliant vs real-world tolerant) — pick the one that fits your use case.
- Click Copy to copy the pattern to your clipboard, ready to paste into your code or the regex tester.
- Verify before deploying. Open the regex tester, paste the pattern, paste a sample of your real data, and confirm matches and non-matches behave as expected.
- Need an explanation? Paste any pattern into the regex explainer to see what every token does.
Pragmatism Over Pedantry
Most "definitive" regex patterns floating around the internet are either too loose (matching obvious nonsense) or too strict (rejecting real input). This library leans pragmatic: each pattern catches the cases you actually encounter in form inputs, log files, and user-generated content, while the Note line is honest about what it skips. The full RFC for an email address runs to several pages and accepts strings most users would consider clearly invalid; the email pattern here is the same one used by most real-world validation libraries because it works.
Two general principles for using regex on real data: first, regex is for finding, not validating. Use it to extract candidate values, then validate each one with a proper parser (new URL(), parseFloat(), the Luhn algorithm). Second, readable patterns beat clever patterns. A 200-character regex that handles every edge case is harder to maintain than a 50-character regex plus a few lines of follow-up validation code. Pick the version that future-you will be able to read.
Frequently Asked Questions
Are these regex patterns RFC-compliant?
Most are practical patterns that catch the cases you actually encounter in real data, not the formal grammar from the relevant RFC. The full RFC 5322 email grammar, for example, runs to several pages and accepts strings most users would consider clearly invalid. Each pattern below has a Note describing what it covers and what it does not, so you can decide whether the trade-off matches your use case. For strict validation, follow the linked guides for language-specific approaches.
Do these patterns work in every regex engine?
The patterns use only common syntax — character classes, quantifiers, anchors, and non-capturing groups — which works identically in JavaScript, Python, Java, Go, .NET, PHP (PCRE), and Ruby. A few patterns use lookahead, which is supported everywhere. None use lookbehind, named groups, or recursive patterns, so they remain portable. If you need to use them in a particular language, check the JavaScript and Python regex guides for any engine-specific gotchas around flags and escape sequences.
Why is the URL pattern so loose?
URL grammar is genuinely complicated — protocol, host, port, path, query, fragment all have their own rules, plus IPv6 addresses, IDN domains, and percent-encoding. A strict pattern would be hundreds of characters and still miss edge cases. The pragmatic approach is to use a loose pattern to find candidate URLs, then validate each candidate by feeding it to your language's URL parser (URL constructor in JavaScript, urllib.parse in Python). Regex finds the URL; the parser tells you if it is structurally valid.
Should I use regex to validate emails?
For form-input validation, a loose regex is fine — it catches obvious typos like missing @ or trailing dots without rejecting unusual but valid addresses. For confirmation that an address actually exists, regex cannot help: only sending a verification email and waiting for the click can prove deliverability. The pattern below is the practical middle ground used by most validation libraries. Do not write a stricter regex hoping to catch every invalid address — you will block valid users instead.
How do I test these patterns?
Click Copy on any pattern, paste it into the regex tester linked at the top of this page, paste a sample of your real data into the test string, and watch matches highlight in real time. The tester runs entirely in your browser, so production data stays local. For an explanation of any unfamiliar token in a pattern, paste the same pattern into the regex explainer for a token-by-token breakdown.