Regex Pattern Library

When a "Correct" Pattern Still Misbehaves in Production

Even a pattern that's individually well-tested can fail once it's dropped into a real pipeline, and the failure is rarely the regex's fault in isolation. The most common cause is an anchoring mismatch: pulling the unanchored IPv4 pattern from this library into a form-validation function that expects a strict full-string match will happily accept 192.168.1.1garbage because nothing stops matching after the last digit. The fix is adding ^ and $ yourself for validation use, and leaving the pattern unanchored only when you're extracting a value from inside a longer string, like a log line.

A second failure shows up when a pattern that works in a browser console silently breaks in a different regex engine. The credit card and SSN patterns here rely on negative lookaheads and alternation groups that JavaScript, Python, and PCRE all support — but Go's regexp package (RE2) rejects lookaheads outright and will fail to compile at all rather than quietly behaving differently, so a pattern copied into a Go service needs rewriting, not just copying. Always test the copied pattern against a handful of real, current examples in the actual target environment — not just the example matches shown on the card — before trusting it in a pipeline, since encoding quirks (like a UTF-8 domain name) can behave differently than the ASCII test cases used to validate the pattern originally.

Where a Careless Regex Becomes a Security Problem

Regular expressions with nested quantifiers over alternation — patterns shaped like (a+)+ or (a|a)* — can exhibit catastrophic backtracking, where a specially crafted input causes the matching engine's runtime to blow up exponentially with input length. This is a genuine denial-of-service vector known as ReDoS: an attacker who can control input to a vulnerable regex (a search box, a log line, an API parameter) can submit a short string that pins a single CPU core at 100% for seconds or minutes, and a handful of concurrent requests like that can take down a service with no other exploit required. Every pattern in this library was written to avoid that shape — none of them nest an unbounded quantifier inside another unbounded quantifier over overlapping character classes — which is exactly the property you should check for before adopting any regex you didn't write yourself, whether from here, Stack Overflow, or a legacy codebase.

The other security-relevant angle is what a pattern is used for: input-validation patterns like the email and URL formats here are a first line of defense against malformed data reaching a database or downstream system, but they are not a substitute for parameterized queries or output encoding — a regex that "validates" an email format does nothing to prevent SQL injection or XSS if the value is later concatenated into a query or rendered unescaped.

Getting More Out of a Shared Pattern Library

• Verify a pattern against your own real data before trusting the example matches: The example column shows representative cases, not exhaustive ones — paste the pattern into the Regex Tester with a handful of your actual production values first.
• Combine narrow patterns with alternation rather than hunting for one universal pattern: If you need to match either an IPv4 or IPv6 address, join the two individual patterns with (pattern1|pattern2) instead of searching for a single expression that tries to do both — narrower patterns are easier to audit for ReDoS risk.
• Treat validation regexes and extraction regexes as different tools: Anchor with ^/$ when rejecting bad input at a form boundary; leave a pattern unanchored only when pulling values out of larger text like logs.
• Re-check secret-detection patterns periodically: Token formats like GitHub's and AWS's prefixes have changed and expanded over time (GitHub added github_pat_ alongside the older ghp_ prefix), so a secret scanner built on a stale pattern can develop blind spots for newer credential formats.

The Regex Dialects Behind These Patterns

Most patterns in this library use syntax that traces back to Perl Compatible Regular Expressions (PCRE), the de facto standard that Python's re, JavaScript's RegExp, Java's Pattern, PHP, and Ruby all implement close variants of. PCRE itself descended from the original POSIX basic and extended regular expression standards, extending them with features like lazy quantifiers, lookaround assertions, and named capture groups that POSIX regex never defined. Tools like grep -E, sed -E, and Nginx's location ~ blocks use POSIX extended syntax, which is a subset — most simple patterns here work unmodified, but anything relying on lookahead (like the SSN pattern's exclusions) needs grep -P for PCRE mode rather than plain extended grep.

How Patterns Are Organized Behind the Scenes

The library itself is a static JavaScript array of pattern objects — category, name, the regex string, and an example string — rendered into cards and filtered entirely client-side as you type in the search box or click a category chip. There's no server-side search index or API call; the filter function runs a simple substring match against the pattern name, category, and example text on every keystroke, which is why results update instantly with no network latency. Copying a pattern uses the same client-side clipboard function as the rest of the site's tools, with backslashes properly escaped so the copied string is a drop-in-ready regex literal rather than a double-escaped mess.

Frequently Asked Questions