What is a regex pattern library, and why not just ask an AI?
A regex pattern library is a fixed set of pre-written, pre-tested regular expressions for common validation and extraction tasks — email addresses, URLs, dates, IP addresses, and so on — organized so you can find the one you need and copy it with confidence. Asking a chatbot for "regex for email" gets you a plausible-looking answer every time, but it is regenerated on the spot and can silently vary in edge-case handling from one request to the next, with no way to see what it does and doesn't match before you ship it. This library takes the opposite approach: every pattern below is static, was tested by hand against real matching and non-matching strings shown right on the card, and stays exactly the same tomorrow as it is today. You get the speed of copy-paste with the transparency of seeing the test cases first.
Categories covered
The 18 patterns are grouped into six categories so you can scan by what you're actually trying to solve rather than hunting through an alphabetical list. Web covers email addresses, HTTP/HTTPS URLs, bare domain names and CSS hex colors. Network covers IPv4 addresses, IPv4 CIDR blocks and IPv6 addresses including the zero-compressed :: notation. Date & Time covers ISO 8601 dates, European DD-MM-YYYY dates and 24-hour clock times. Identifiers covers version-4 UUIDs, URL slugs, plain numbers, usernames and North American phone numbers. Security covers strong-password rules and a basic credit-card digit-grouping shape check. Location covers US ZIP and ZIP+4 codes. Each category button in the filter bar narrows the list instantly, and the search box matches against the pattern name, category and description text.
How to use this tool
Search or filter by category to find the pattern you need — email, network, date & time, identifiers, security, or location. Each card shows the regex itself, which you can toggle between anchored (must match the whole input, for form validation) and unanchored (matches a substring anywhere, for extracting values out of a larger block of text), plus optional i (case-insensitive) and g (global, find all matches) flags. Below that, green and red example strings show exactly what the pattern accepts and rejects. Paste your own text into the "Try it" box at the bottom of any card to see live matches highlighted as you type. Click "Copy" to grab the full regex literal, ready to paste into your code, a form's pattern attribute, or a linter config.
Example 1 — validating a form field (anchored)
Input field value: jane.doe+newsletter@my-company.co. Using the anchored Email address pattern ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$:
Input: "jane.doe+newsletter@my-company.co"
Test: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(input)
Output: true → the whole string is a syntactically valid address, safe to accept
Input: "jane.doe@my-company" Output: false → no dot-separated top-level domain, correctly rejected
Example 2 — extracting matches from free text (unanchored + global)
A support ticket contains: "Deploy failed on 2026-07-11, retry scheduled for 2026-07-12. Server IP is 192.168.4.12." Running the unanchored, global ISO date pattern \d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]) against it:
matchAll(/\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])/g, text)
Output: ["2026-07-11", "2026-07-12"] → both dates extracted, IP address correctly ignored
Running the IPv4 pattern on the same text instead Output: ["192.168.4.12"] → the IP is extracted, dates are correctly ignored
Frequently asked questions
Where do these regex patterns come from and can I trust them?
Every pattern in this library was hand-written and hand-verified against a set of matching and non-matching example strings shown right on the card — you can see exactly which inputs pass and which fail before you copy anything. None of them are generated by an AI model at request time; this is a fixed, curated reference, so the same input always produces the same result and there is nothing to hallucinate.
What does the anchored toggle actually change?
Anchored wraps the pattern in ^ and $ so it must match the entire string from start to end, which is what you want for form validation (is this whole input a valid email?). Unanchored removes the anchors so the pattern can match a substring anywhere inside a larger block of text, which is what you want for extracting or highlighting matches inside a document, log file, or paragraph.
Why is the email regex here simpler than the official RFC 5321 grammar?
The full RFC 5321 email grammar allows quoted strings, comments, and IP-literal domains that almost no real mail server actually accepts, and a regex that implements it correctly is thousands of characters long and still can't tell you if the mailbox exists. The pattern here matches the shape real-world addresses take — this is a syntax check, not proof of deliverability. If you need certainty, send a confirmation email; that is the only real test.
Does this tool send my test text to a server to check matches?
No. Every regex is compiled and executed by your browser's built-in JavaScript engine using the native RegExp object. There is no fetch, no analytics beacon, and no network request after the page first loads, so pasting sensitive data — internal hostnames, real customer emails, production log lines — into the live tester never leaves your machine.
Can I use these patterns directly in Python, Java, or other languages?
Almost all patterns here use standard PCRE-compatible syntax (character classes, quantifiers, groups, lookaheads) that works unchanged in Python's re module, Java's Pattern class, PHP's PCRE functions, and most other mainstream regex engines. JavaScript-specific flags shown next to the pattern (g, i) map directly to re.IGNORECASE style flags elsewhere — check your language's flag syntax, but the pattern body itself is portable.
Which pattern should I use to validate an international phone number?
The phone pattern in this library targets US/Canada 10-digit numbers with an optional +1 prefix, because a single regex cannot correctly validate every country's numbering plan — lengths and formats vary too much by region. For real international phone validation, use a maintained library such as libphonenumber, which encodes the actual numbering plans per country; treat the regex here as a quick shape check for North American numbers only.