Regex Reference

Most developers do not need to write a regular expression from scratch — they need a pattern that already works. This Regex Reference is a compact cheat sheet of 30 ready-to-use expressions plus a 24-entry guide to the syntax tokens those expressions are built from. Every pattern card includes the raw regex, a description, and an example string it matches, so you can copy, test, and adapt without guessing.

What the Reference Contains

The pattern library is organized by intent, not by syntax.

Category	Count	Examples
Validation	12	Email, URL, IPv4, phone, ISO date, time, strong password, US ZIP, credit card, SSN, username, IPv6
Web	5	Hex color, HTML tag with content, CSS rgb(), MD5 hash, SHA-256 hash
Numbers	5	Integer, decimal, percentage, USD currency, scientific notation
Formatting	5	Slug, camelCase, PascalCase, snake_case, kebab-case
Strings	3	Trim whitespace, doubled words, file extension

That is 30 patterns in total. The syntax guide adds 24 tokens split across seven categories: anchors, quantifiers, character sets, groups, character escapes, alternation, and lookaround.

Pattern Categories in Detail

Validation patterns are the largest group because form checking is the most common reason people reach for regex. The IPv4 pattern is a good example of careful construction: rather than \d{1,3} repeated four times, it constrains each octet to 0-255, so 192.168.1.1 passes and 192.168.1.999 fails. The password pattern uses four positive lookaheads to require a lowercase letter, an uppercase letter, a digit, and a symbol, then matches at least 8 characters from the combined set.

Web patterns extract or verify the values that show up in markup and stylesheets: a 3- or 6-digit hex color, an HTML tag with its matching close tag via a backreference, an rgb() function, and the fixed 32- and 64-character shapes of MD5 and SHA-256 digests.

Numbers covers signed integers, decimals, percentages, thousands-separated USD amounts, and scientific notation such as 6.022e23.

Formatting patterns test identifier styles — my-blog-post, myVariableName, MyClassName, my_variable_name, my-css-class — which is useful for lint rules and naming conventions.

Strings rounds out the set with leading/trailing whitespace, repeated consecutive words (\b(\w+)\s+\1\b), and trailing file extensions.

Syntax Tokens, Explained by Category

The token table is the teaching half of the page. Anchors (^, $, \b, \B) pin a match to a position. Quantifiers (*, +, ?, {n}, {n,}, {n,m}) control repetition. Character sets ([abc], [^abc], .) define what a single position may hold. Groups ((...), (?:...), \1) capture or reuse text. Escapes (\d, \w, \s and their negations \D, \W, \S) are shorthand classes. Alternation (|) chooses between expressions, and (?=...) is a positive lookahead that asserts what comes next without consuming it.

Worked Example: Reading the URL Pattern

The URL entry is stored as:

^https?://[\w.-]+(:\d+)?(/[\w./%+-]*)?(\?[\w%&=.-]*)?(#\w*)?$

Break it down piece by piece. ^https?:// requires http:// or https://. [\w.-]+ matches the host from word characters, dots, and hyphens. (:\d+)? accepts an optional port. (/[\w./%+-]*)? takes an optional path. (\?[\w%&=.-]*)? and (#\w*)? allow a query string and a fragment. Because every optional group ends in ?, https://example.com matches with no path at all. It will not match a bare example.com, a scheme like ftp://, or a path containing characters outside that set — all reasonable trade-offs for a short, readable pattern, but limits you should know before shipping it.

Worked Example: What the Email Pattern Accepts

The email entry is:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Read it left to right. ^ anchors the match at the start. [a-zA-Z0-9._%+-]+ consumes one or more letters, digits, dots, underscores, percent signs, plus signs, or hyphens for the local part. @ is a literal at-sign. [a-zA-Z0-9.-]+ takes the domain. \. is a literal dot, and [a-zA-Z]{2,} requires at least two trailing letters for the top-level domain. $ anchors the end.

Applied to sample input:

Input	Result	Why
user@example.com	Matches	Simple local part, two-letter TLD
first.last+tag@mail.co.uk	Matches	Dots and plus are in the local set; TLD has two letters after the final dot
user@example	Rejected	No dot-and-letters suffix
"user name"@example.com	Rejected	Spaces and quotes are not in the local class
user@exa mple.com	Rejected	The domain class excludes spaces

That last pair is the important lesson. Rejecting a space is correct, but rejecting a quoted local part is a limitation of the simplified pattern, not of email. If you need RFC-level acceptance, pair this regex with a confirmation email rather than trusting the pattern alone.

Known Limits of the Bundled Patterns

These patterns are starting points, not authority. The email and URL entries are deliberately loose to avoid rejecting valid input; a strict RFC 5322 email validator is far longer and still imperfect, which is why sending a confirmation message is the real test. Catastrophic backtracking is a risk if you nest the provided groups inside other quantifiers, so test any adapted pattern against hostile input. Finally, engines disagree: lookbehind, named groups, and Unicode property escapes behave differently across JavaScript, Python, and Go, so the same string can match in one runtime and fail in another. Always run a copied pattern where it will actually execute.

Related Tools

• Regex Tester — Test patterns with live match groups and flags.
• Diff Checker — Compare text line by line.
• Text to Slug — Turn titles into URL-friendly slugs.