Free Regex Pattern Library

About This Library

This is a curated, searchable collection of 60+ commonly-used regular expression patterns organized by category. Each pattern includes a description, the regex itself, and example matches. Click any pattern to copy it, or use the quick-test panel to validate text against it right on this page.

Everything runs in your browser · no patterns or test strings are sent anywhere. Use these patterns in JavaScript, Python, PHP, Java, Go, or any language that supports regular expressions. For more advanced testing with flags and capture groups, try our Regex Tester.

Where regular expressions come from

The mathematical idea of a «regular set» was formalised by Stephen Cole Kleene in 1951 in the RAND research memorandum Representation of Events in Nerve Nets and Finite Automata. The * operator on this page is still called the Kleene star in his honour. Ken Thompson turned the theory into an algorithm in his June 1968 Communications of the ACM paper Programming Techniques: Regular Expression Search Algorithm, and shipped the first regex implementation in the QED editor at Bell Labs. By 1973 the same engine powered ed, then grep (the literal expansion is «globally search for regular expression and print»), sed, and awk. Larry Wall's Perl (1987) and especially Perl 5 (1994) added named groups, lookaround, non-greedy quantifiers and Unicode handling that became the de-facto dialect known as PCRE, ported to C as a library by Philip Hazel in 1997.

Engine flavors and what changes between them

A pattern that runs cleanly in JavaScript can silently fail in Go and outright reject in POSIX. The five flavors a developer is most likely to meet:

• POSIX BRE / ERE (IEEE Std 1003.2-1992): the dialect of grep, sed, and awk on a stock Unix system. No lookaround, no named groups, no Unicode property escapes. BRE additionally requires escaping (, ), {, }, and |.
• PCRE2 (Philip Hazel, 1997, current major version 10.x): the most feature-complete dialect. Lookaround, named groups (?<name>...), atomic groups, possessive quantifiers, recursion. Used by PHP preg_*, Apache, nginx, R.
• ECMAScript regex (ECMA-262, regex section 22.2): the JavaScript dialect. ES2018 added named groups, lookbehind, and the s (dotAll) and u (Unicode) flags. ES2022 added the d flag for match indices. ES2024 added the v flag with set-notation classes.
• Python re: close to PCRE, but uses (?P<name>...) for named groups (PEP 433) and a different verbose mode re.X. The newer regex third-party module adds recursive patterns and POSIX longest-match semantics.
• RE2 (Russ Cox, 2010): the engine behind Go's regexp and Rust's regex crate. No lookaround, no backreferences, no possessive quantifiers, on purpose. The tradeoff: guaranteed linear time, no catastrophic backtracking. If a pattern from this library uses (?=...) or \1, it will not compile in Go.

Catastrophic backtracking and ReDoS

Most regex engines in mainstream languages (PCRE, Java, JS V8 / SpiderMonkey / JavaScriptCore, Python re, .NET) are backtracking engines. When a pattern with nested quantifiers like (a+)+ hits an input that almost matches, the engine can try an exponential number of alternative paths before giving up. This is catastrophic backtracking, and it is the basis of the ReDoS (Regular expression Denial of Service) attack class catalogued by OWASP.

Stack Overflow, 20 July 2016: a pattern designed to trim leading and trailing whitespace, applied to a question body containing 20,000 consecutive whitespace characters, took 11 minutes of CPU per request and made the site unresponsive for 34 minutes. The post-mortem on the official Stack Status blog recommended replacing trim regexes with native string trim.

Cloudflare, 2 July 2019: a WAF rule containing the nested-quantifier pattern .*(?:.*=.*) was deployed globally and consumed 100% CPU on every edge server for 27 minutes, taking large portions of the public internet offline. Cloudflare's post-mortem on their blog credited the switch to Rust's regex crate (an RE2-based, linear-time engine) for preventing recurrence.

The defensive lessons: avoid nested quantifiers ((a+)+, (a*)*, (a|aa)+); avoid \s+$-style trims on attacker-controlled input; prefer atomic groups (?>...) or possessive quantifiers a++ in PCRE; and for high-throughput services consider an RE2-based engine.

Email, URL, phone, date, credit card: when not to use regex

Email. The full grammar of RFC 5322 (October 2008) compiles to a regex about 3,000 characters long. The W3C HTML5 specification for <input type="email"> validation uses a much shorter «is-this-plausibly-an-email» regex which is the right starting point for client-side hints. RFC 6531 (February 2012) permits non-ASCII addresses like 用户@example.com, which an ASCII-only regex will incorrectly reject. The industry consensus since RFC 6532: do not validate emails with regex, send a verification email instead.

URLs. RFC 3986 (January 2005) is the URI generic-syntax spec, but the WHATWG URL Living Standard deliberately diverges from it to match what browsers actually accept. Use new URL("...") in JavaScript or urllib.parse in Python rather than a regex for anything beyond a quick visual check.

Phone numbers. ITU-T Recommendation E.164 (current revision November 2010) allows up to 15 digits with an optional + prefix, but country-specific rules vary enormously. Google's open-source libphonenumber library encodes the per-country rules for every territory and is the only reliable cross-country validator.

Dates. A regex like ^\d{4}-\d{2}-\d{2}$ matches the ISO 8601-1:2019 calendar format, but it also accepts 2026-02-31. Date validity requires calendar logic, not pattern matching; use Date.parse() or a date library.

Credit cards. A regex can match the digit length and IIN prefix (Visa starts with 4, Mastercard with 51-55 or 2221-2720, Amex with 34 or 37) but cannot verify the Luhn checksum (Hans Peter Luhn, IBM, US Patent 2,950,048 granted August 1960). Luhn requires a digit-by-digit sum modulo 10.

Common ways developers use this library

• Client-side form hints, with the understanding that a regex catch is a hint, not a final validation.
• Log scraping, pulling timestamps, IPs, error codes, and URLs out of application logs into a pipeline.
• One-off data cleanup: normalising whitespace, stripping HTML tags, converting between date formats, slugifying titles.
• Editor find-and-replace in VS Code, Sublime, vim, IntelliJ where the regex flavor is close to PCRE.
• Router and URL match patterns in Express, Flask, FastAPI, Rails.
• WAF and intrusion-detection rules: with extreme care about ReDoS as the Cloudflare 2019 incident demonstrated.
• Quick string testing in this page's bottom-of-screen test panel, before committing the pattern to code.

Common mistakes

• Forgetting the anchors. Without ^ and $ (or \A and \z in PCRE), a validation regex matches if the pattern appears anywhere in the string. /\d{4}/ matches «year 2026 was good», which is almost never what you want.
• Trusting .* across multiple things. <a href=".*"> on the input <a href="a"><a href="b"> captures across both tags because .* is greedy. Use .*? for lazy, or better, parse with a real parser.
• Assuming the dot matches newlines. By default . matches everything except line terminators. Use the s (dotAll) flag in JS, or re.DOTALL in Python, or the inline modifier (?s) in PCRE.
• Assuming \w includes non-ASCII letters. In ASCII mode, \w is [a-zA-Z0-9_]. Add the u flag in JS (ES2018+) and use \p{L} for any Unicode letter; in Python add re.UNICODE (default in Python 3).
• Backreferences in Go. Go's regexp is RE2 and rejects \1 at compile time. The error «error parsing regexp: invalid escape sequence: \1» means the pattern needs to be split into a non-regex approach.
• Parsing HTML with regex. Famously infeasible: HTML is not a regular language. Use a DOM parser (the browser's built-in DOMParser, cheerio, BeautifulSoup, lxml).

More frequently asked questions

Why do some patterns use (?:...) instead of (...)?

(?:...) is a non-capturing group: it groups for repetition or alternation but does not allocate a backreference slot. It is faster and avoids polluting $1, $2 in the result array. Use (...) when you need to extract the captured text; use (?:...) for grouping alone.

What are the most common regex flags?

i case-insensitive, g global (find all, JS-specific behaviour), m multiline (so ^ and $ match line boundaries), s dotAll (so . matches newlines, ES2018+), u Unicode (ES2015+), y sticky (ES2015+), d hasIndices (ES2022+), v set-notation classes (ES2024+). Combine as /pattern/gimsu.

How do I match a literal special character?

Escape it with a backslash. The regex metacharacters that need escaping when you want a literal match are: . ^ $ * + ? ( ) [ ] { } | \ /. Inside a character class [...] the set of special characters is smaller: only ] \ ^ - need escaping, depending on position.

Can I use this library's patterns in shell scripts?

Yes, with caveats. grep uses POSIX BRE by default; grep -E uses ERE; grep -P uses PCRE on systems where libpcre is linked (GNU grep, macOS grep with Homebrew). Patterns using lookaround, named groups, or Unicode property escapes need grep -P or ripgrep (which uses Rust's RE2-based engine and rejects lookaround).

Are these patterns sent to a server?

No. Every regex on this page, every search you type, and every string you test in the quick-test panel is processed in your browser's JavaScript engine. No network call is made. The pattern data itself is shipped as a static JSON file in the page bundle. Open the Network tab in DevTools to verify.