DevLab
.*
Regex⭐ Popularbeginner

Common Regex Patterns

browse and copy 100+ common regex patterns for email, URL, phone, and more

By Bikram NathLast updated

This is a reference library of 100+ tested regex patterns for email, URL, phone, date, credit card, and IP address validation -- each copyable and testable against your own input without leaving the page. The email patterns go beyond the naive [^@]+@[^@]+ shortcut and correctly handle subdomains and multi-part TLDs. Unlike regex101, patterns here are pre-categorized so you are finding rather than building.

Try it now — free, instant, no signup

What is Common Regex Patterns?

The tool is a searchable library of pre-written regular expressions grouped by category: email, URL, phone number, date, credit card, IP address, and more. Instead of copying a pattern from a Stack Overflow answer of unknown age, you pick a category, inspect the pattern, and test it against your own string in the same interface. A phone number pattern, for example, lets you paste a sample like '+44 7911 123456' and confirm it matches before dropping the regex into your codebase.

Developers reach for this when they need a verified starting point rather than a blank editor. regex101 is the right choice when you are debugging an unfamiliar pattern or need its step-by-step match explanation and flavor selector. This library fits the opposite situation: the problem is common enough that a known-good pattern already exists and the job is retrieval, not construction.

One technical note that matters in practice: JavaScript's RegExp engine gained lookbehind assertions ((?<=...) and (?<!...)) in ECMAScript 2018, but Safari did not ship them until version 16.4, released March 2023. If a pattern in the library uses a lookbehind, it will throw a SyntaxError in older Safari. Check MDN's browser compatibility table before shipping a lookbehind-dependent pattern to a consumer product with broad Safari coverage.

When to use Common Regex Patterns

Grab a pre-tested credit card pattern to add client-side format validation before a Stripe API call, cutting unnecessary round-trips on malformed input.
Audit a legacy codebase's homegrown email regex by comparing it against the library's version to spot exactly where the in-house one breaks.
Prototype a multi-country phone validation field without spending 30 minutes researching E.164 format rules and country-code prefix ranges from scratch.

Frequently Asked Questions

Do the email patterns here handle the full RFC 5322 specification?
No, and intentionally so. A fully RFC 5322-compliant email regex runs to several hundred characters and permits constructs like quoted local parts with spaces, which virtually no real mail server accepts in practice. The patterns here target practical validity: formats a real user will submit in a web form. If you need strict RFC compliance for a mail server or standards-conformant parser, a dedicated library like 'email-validator' in Node.js or Python's 'email.headerregistry' module will handle edge cases that a regex structurally cannot.
Why do the URL patterns fail to match localhost or bare IP addresses?
Most general-purpose URL patterns anchor the hostname segment to a TLD requirement designed for public web addresses. A URL like 'http://localhost:3000/api' fails because 'localhost' has no dot-separated suffix, and 'http://192.168.1.1' fails because the octets do not match an alphabetical hostname pattern. For internal tooling, copy the base pattern and modify the hostname segment to allow numeric octets or omit the TLD check. The live test field lets you paste your specific case and confirm exactly where the match breaks before editing.
Can these patterns be used directly in Python, Go, or Java, or are they JavaScript-specific?
Most patterns transfer across flavors since character classes, quantifiers, and anchors are consistent. The main friction points are named capture groups (JavaScript and Python both use (?<name>...) while Go requires (?P<name>...)) and lookbehind assertions (Go's RE2 engine omits them entirely, so any pattern using (?<=...) must be restructured). Java's java.util.regex supports both lookbehinds and named groups using the same syntax as Python, making it the easiest transplant target for patterns that rely on those features.
Why does the date regex match February 31st or April 31st as valid?
Regex operates on character sequences, not calendar semantics. A pattern like \d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]) confirms the digits fall in plausible ranges but cannot cross-reference a month against its actual day count. Catching February 31st requires a parse step: in JavaScript, pass the matched string to new Date() and check isNaN(date.getTime()). Use regex to gate the format, then a date parser to gate logical validity. This two-step approach is standard practice and intentional, not a gap in the pattern.
Which IP address pattern covers IPv6 as well as IPv4?
IPv4 and IPv6 need separate patterns because their structure differs fundamentally. An IPv4 pattern checks four octets in the 0-255 range. A correct IPv6 pattern is substantially more complex because the format permits compressed notation (::1), mixed IPv4-IPv6 notation (::ffff:192.0.2.1), and zone IDs. For IPv6, the pattern maintained in the 'ip-regex' npm package or the one from Perl's Regexp::Common module has broader test coverage than most hand-rolled alternatives. Confirm which format your data source actually produces before choosing, since mixing them in one pattern introduces false positives.

Related Tools