Common Regex Patterns: the Copy-Paste Library

Email regex: the simple, the practical and the strict

Email is the most requested regex pattern and the most misunderstood. The fully RFC 5322-compliant pattern is over 6,000 characters long, which is why every serious project picks a pragmatic middle ground. The rule of thumb: validate structure with regex, confirm existence with a confirmation email. Anything stricter than the patterns below rejects real addresses that are legal.

Why not one perfect email regex? Legal addresses can contain quoted local parts, IP-literal domains and comments. The practical pattern above covers 99%+ of real-world signups; the confirmation email covers the rest.

URL regex: http(s) links without the false positives

A URL pattern can balloon quickly once you try to honor every RFC 3986 detail. The versions below cover what form fields and log parsers actually need: an optional scheme, a host, and an optional path, query string and fragment. The match-anywhere variant is the one to use when you are extracting links from text rather than validating a whole input.

For extraction, the lazy class [^\s"'<>]+ is the workhorse: it grabs everything up to the first whitespace or angle bracket, which is where URLs end in HTML and prose.

Phone number regex: US formats and international E.164

Phone regex fails when it tries to be too clever about what humans type. Decide your contract first: if the field is "US phone, any common format", use the first pattern; if you store to a database, prefer E.164 (the international standard) and validate that instead. Formatting variants like 1 (555) 123-4567 ext. 88 all pass the US pattern because the separators are optional classes, not literals.

The US pattern accepts mismatched brackets like (555-123-4567. If you care, validate bracket pairing in application code — regex purity is not worth it here.

Date regex: formats and the leap-year trap

Regex can enforce the shape of a date and even most of its calendar rules, but no simple regex fully validates leap years — the strict ISO pattern below is the exception, and it is included because the leap-year branch is a classic teaching example. For everything else, match the shape with regex and confirm real calendar validity with your language's date parser.

Use the leap-year branch when the regex is the only gate (config files, quick scripts). In application code, a Date constructor or datetime parser is cheaper and clearer.

Password strength regex: one pattern per rule

Two adjustments are common. To require at least three of four character classes instead of all four, use alternation of lookaheads instead of a single chain. To allow any special character rather than a fixed list, replace the class with a negated alphanumeric class — but be careful, because "any non-alphanumeric" includes spaces, which most password policies do not want to permit silently.

const strongPassword =
  /^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%^&+=!]).{8,24}$/;

strongPassword.test("Ship1t@26");   // true
strongPassword.test("shipit2026");  // false — no uppercase, no special
strongPassword.test("SH1T@");       // false — under 8 characters

Numbers, money and decimals

Number formats look trivial and are not: negative signs, thousand separators, optional decimals and currency symbols each double the pattern's size. The versions below are the ones that survive contact with real form input. Note that the comma-separated pattern intentionally requires groups of exactly three digits, which is what separates 1,234,567 from accidentally matching 12,34.

Text-processing workhorses: slugs, tags, colors, IPs

These are the patterns developers paste ten times a day. They are deliberately minimal — the goal is a reliable building block, not full spec compliance. The hex color pattern accepts both the 3-digit and 6-digit forms with optional # prefix; the IPv4 pattern validates octet ranges arithmetically instead of enumerating 0-255 character by character, which keeps it readable.

Parsing HTML with regex is fine for extracting simple tags; it is not fine for rendering or security decisions. For anything structural, use a real DOM parser — and sanitize any HTML you render (this site's tools run every rendered document through DOMPurify for exactly that reason).

How to adapt a pattern to your language

The patterns above are written in JavaScript/ECMAScript flavor. Most translate by copy-paste, but three differences bite people regularly. First, delimiters: JavaScript often shows patterns wrapped in forward slashes, while Python's re module takes the bare pattern string — drop the slashes and any trailing flags when porting. Second, backslash escaping: in a Python raw string r"\d" reaches the engine intact, but in a normal JavaScript string literal you need "\\d" — which is why the code examples on this page double the backslashes while the tables show the raw pattern.

Third, lookaround support: lookbehind (?<=...) landed in ECMAScript 2018, so older Safari versions throw on patterns that work everywhere else. Go's regexp engine (RE2) omits lookarounds entirely by design for performance guarantees — when you need one in Go, invert the logic and match the surrounding context instead. Python's re module supports lookaheads and fixed-width lookbehinds; the third-party regex module relaxes the fixed-width limit.

Test before you ship: the two-minute loop

Every pattern in this library is one paste away from a live match view. The fastest workflow: open the regex tester, paste the pattern, paste a few lines of real (and adversarial) sample text, and check the highlight and capture groups. Adversarial samples matter more than happy-path ones — the phone pattern that matches every example in your test file may still accept (555-123-4567 with a mismatched bracket.

When a match misbehaves, the usual suspects are greediness (add the lazy ?), the m flag changing what ^ and $ mean, and forgetting that the dot does not cross newlines without the s flag. The cheat sheet explains each of these tokens in depth with examples, and the diff checker is handy for eyeballing what a find-and-replace actually changed across a file.

• Happy-path sample plus three adversarial ones: too short, wrong separator, malicious input.
• Check capture groups — the text you extract is usually group 1, not the whole match.
• Test the replace view before running a regex against production files.

Questions this guide answers

• common regex patterns
• regex pattern
• regex email validation
• regex for url
• regex phone number
• regex date pattern
• regex generator