Regex Pattern Library: Common Patterns Explained With Examples

Every pattern below is shown with what it actually matches and what it actually rejects — no pattern here is claimed to do more than it does. Paste any of them into GenKitLab's Regex Tester to see the match highlighted live against your own strings before you commit one to code. For email specifically, there's a full breakdown of edge cases — plus-addressing, subdomains, Unicode — in the regex for email validation guide; it isn't repeated here.

Matches the common written forms of a 10-digit US phone number, with or without a leading area code in parentheses and with dashes, dots or spaces as separators.

^\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$

Matches:
(555) 123-4567
555-123-4567
5551234567

Rejects:
+44 20 7946 0958   (not US-format)
555-12-4567        (wrong grouping)

This pattern is US-format-specific on purpose — it assumes exactly 10 digits grouped 3-3-4. An international number has a different length, an optional country code, and different grouping conventions entirely, so this same shape can't be stretched to cover it; a permissive international pattern needs to allow a leading + and a much wider digit-count range instead.

A pragmatic “does this look roughly like a URL” check — it requires an http or httpsscheme and at least one non-whitespace character afterward that isn't itself a slash, dot or a few other leading punctuation marks.

^https?:\/\/[^\s/$.?#].[^\s]*$

Matches:
https://example.com
http://sub.example.com/path?query=1

Rejects:
example.com          (no scheme)
https://              (nothing after the scheme)

A fully spec-correct URL regex — one that validates every valid scheme, IPv6 host literal, and percent-encoded path per RFC 3986 — is impractical to hand-write and even harder to read six months later. The more reliable second check, once a string passes a loose pattern like this one, is to actually construct a URLobject (or your language's equivalent parser) and let it throw on anything genuinely malformed. The regex is a fast first filter, not the final word.

Matches a CSS hex color in either its full 6-digit form or the 3-digit shorthand, with a required leading #.

^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$

Matches:
#1a2b3c
#fff
#FFFFFF

Rejects:
#12345     (5 digits — wrong length)
#gggggg    (g is not a valid hex character)

Matches a lowercase, dash-separated slug: one or more lowercase letters or digits, followed by zero or more groups of a single dash plus more lowercase letters or digits.

^[a-z0-9]+(?:-[a-z0-9]+)*$

Matches:
my-blog-post-title
release-2026

Rejects:
My Blog Post!    (uppercase and a space and punctuation)
-leading-dash    (can't start with a dash)
double--dash    (a dash must be followed by an alphanumeric, not another dash)

Be precise about what this pattern actually does, rather than assume: each (?:-[a-z0-9]+) repetition requires the dash to be immediately followed by one or more alphanumeric characters, so a second dash right after the first one has nothing valid to match against and the whole pattern fails at the $ anchor. That means double--dash is already rejected by this exact pattern, with no extra tightening needed — a trailing or leading dash is what actually needs a separate check, since my-post- also fails here (nothing follows the final dash) while a title-cased or space-containing input like My Blog Post! fails for the more obvious reason that uppercase letters, spaces and ! simply aren't in the [a-z0-9] class at all.

Requiring “at least one uppercase, one lowercase, one digit, one special character, and 8+ characters total” can't be expressed as a single straightforward character class — a class like [A-Za-z0-9\W_]only says “any one of these character types is allowed here,” it can't say “all four types must appear somewhere in the string.” That's exactly what lookaheads are for: each (?=...) checks the whole string for one required condition without consuming any characters, so several of them can be chained together before the actual length check runs.

^(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[\W_]).{8,}$

Matches:
Str0ng!Pass
Xk9$abcd

Rejects:
password        (no uppercase, digit, or special character)
Password1       (no special character)
Sh0rt!          (only 6 characters, needs 8+)

• (?=.*[A-Z]) — at least one uppercase letter, anywhere in the string.
• (?=.*[a-z]) — at least one lowercase letter, anywhere.
• (?=.*\d) — at least one digit, anywhere.
• (?=.*[\W_])— at least one character that's not a word character, or an underscore (underscore is otherwise treated as a word character by \W, hence adding it explicitly).
• .{8,} — the actual length requirement, checked last once every lookahead has passed.

A quick shape check for four dot-separated groups of one to three digits — useful for a fast first filter, not a full validator.

^(\d{1,3}\.){3}\d{1,3}$

Matches (shape-wise):
192.168.1.1
10.0.0.255
999.999.999.999   ← matches the shape, but isn't a valid IP

That last line is the pattern's known weakness, stated plainly: it never range-checks each octet against 0-255, so 999.999.999.999passes the regex even though no real IPv4 address can have an octet above 255. A fully correct IPv4 regex exists and range-validates each segment individually, but it's considerably longer and harder to read for the gain of one comparison. The pragmatic approach most real code takes instead: match this loose shape with the regex, then split on . and check numerically that each of the four parts parses to an integer between 0 and 255. Let the regex catch the shape; let arithmetic catch the range.

Two small utility patterns that show up constantly in form-cleanup and text-normalization code — trimming leading/trailing whitespace, and collapsing repeated internal whitespace to a single space.

^\s+|\s+$

"  hello world  " → matched at both ends, replace with "" to trim
→ "hello world"

\s+  →  replace every match with a single space " "

"too    many   spaces" → "too many spaces"

In practice, most languages already ship a dedicated .trim()method that's faster and clearer than a regex for the pure-trim case — the regex version is worth knowing mainly because it generalizes: the same \s+ building block collapses internal runs of whitespace, which .trim()alone can't do.

Every pattern on this page runs exactly the same in GenKitLab's Regex Tester — paste one in alongside your own sample strings and see the match highlighted, capture groups named, and a replace preview before anything reaches production code. If a pattern needs building up from a description or from labeled examples rather than copied from a list, the Regex Generator guide covers building one from scratch, and the email validation guide covers the one pattern intentionally left out of this list.