Regex Cheat Sheet — The Complete Regular Expression Reference

Character classes match a single character from a set of possibilities. They're the building blocks of nearly every regex pattern.

• . — Matches any character except newline. The most general wildcard.
• \d — Matches any digit (0-9). Equivalent to [0-9].
• \D — Matches any non-digit character.
• \w — Matches any word character: letters, digits, and underscore. Equivalent to [a-zA-Z0-9_].
• \W — Matches any non-word character.
• \s — Matches any whitespace character: space, tab, newline, carriage return.
• \S — Matches any non-whitespace character.
• [abc] — Matches any one of the listed characters (a, b, or c).
• [^abc] — Matches any character NOT in the list.
• [a-z] — Matches any character in the range (lowercase a through z).

Character classes can be combined and nested. For example, [a-zA-Z0-9] matches any alphanumeric character, and [\d.] matches a digit or a period — useful for matching decimal numbers.

A common mistake is forgetting to escape special characters inside character classes. The dash - must be escaped or placed at the start/end of the class: [a\-z] or [-az]. The caret ^ only negates if it's the first character.

Quantifiers control how many times the preceding element must occur. They're what make regex patterns flexible enough to match real-world text.

• * — Zero or more times. a* matches "", "a", "aa", "aaa", etc.
• + — One or more times. a+ matches "a", "aa", "aaa", but not "".
• ? — Zero or one time. Makes the preceding element optional. colou?r matches both "color" and "colour".
• {n} — Exactly n times. \d{4} matches exactly four digits.
• {n,} — n or more times. \d{2,} matches two or more digits.
• {n,m} — Between n and m times. \d{1,3} matches 1 to 3 digits.

By default, quantifiers are greedy — they match as many characters as possible. Add ? after any quantifier to make it lazy (match as few as possible). For example, .*? matches the minimum number of characters, which is crucial when parsing HTML tags: <.+?> matches a single tag rather than everything between the first and last tag.

Understanding greedy vs. lazy matching is one of the most important regex concepts. If your pattern matches more text than expected, switching to a lazy quantifier is usually the fix.

Anchors don't match characters — they match positions in the string. They ensure your pattern matches at the right location.

• ^ — Matches the start of the string (or start of a line in multiline mode).
• $ — Matches the end of the string (or end of a line in multiline mode).
• \b — Word boundary. Matches the position between a word character and a non-word character. \bcat\b matches "cat" but not "category" or "scattered".
• \B — Non-word boundary. Matches any position that is NOT a word boundary.

Anchors are essential for validation patterns. Without ^ and $, a pattern like \d{5} would match "12345" inside "abc123456def" instead of only matching strings that are exactly 5 digits. Always use ^\d{5}$ when validating that the entire input matches.

Word boundaries (\b) are particularly useful for search-and-replace operations. If you want to replace the word "cat" but not "category," wrapping it in word boundaries prevents partial matches.

Groups let you treat multiple characters as a single unit, apply quantifiers to sequences, and extract matched text.

• (abc) — Capturing group. Matches "abc" and remembers the match for backreferences or extraction.
• (?:abc) — Non-capturing group. Groups the pattern but doesn't capture. Slightly more efficient when you don't need the captured value.
• (?<name>abc) — Named capturing group. Matches and captures with a name, making complex patterns more readable.
• \1, \2 — Backreference to captured group. (\w+)\s+\1 matches repeated words like "the the".
• (a|b) — Alternation. Matches either "a" or "b".

Groups are how you extract data from matched text. For example, the pattern (\d{4})-(\d{2})-(\d{2}) matches dates like "2026-04-03" and captures the year, month, and day as separate groups. In most programming languages, you can access these captures by index or name.

Named groups ((?<year>\d{4})) are a best practice for complex patterns because they make the code that uses the regex much more readable than numeric backreferences like \1.

Lookarounds assert that something exists (or doesn't exist) before or after the current position, without including it in the match. They're "zero-width assertions" — they check a condition without consuming characters.

• (?=abc) — Positive lookahead. Asserts that "abc" follows the current position.
• (?!abc) — Negative lookahead. Asserts that "abc" does NOT follow.
• (?<=abc) — Positive lookbehind. Asserts that "abc" precedes the current position.
• (?<!abc) — Negative lookbehind. Asserts that "abc" does NOT precede.

Lookarounds are powerful for matching patterns based on context. For example, \d+(?=px) matches numbers followed by "px" (like "16" in "16px") but doesn't include "px" in the match. This is useful when you want to extract values without their units or labels.

A practical example: password validation. (?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,} uses multiple positive lookaheads to assert that the string contains at least one digit, one lowercase letter, one uppercase letter, and is at least 8 characters long — all without specifying their order.

Here are battle-tested patterns for the most common validation tasks. Note that "perfect" regex for these is nearly impossible — these are practical patterns that work for the vast majority of real-world input.

Email (practical):

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

This covers the vast majority of real email addresses. The full RFC 5322 spec allows quoted strings, comments, and other obscure formats that virtually no one uses. This pattern is the right trade-off between correctness and readability.

URL (HTTP/HTTPS):

^https?:\/\/[\w.-]+(?:\.[\w]{2,})(?:\/[^\s]*)?$

Matches URLs starting with http:// or https://, followed by a domain name with a TLD, and an optional path. For more complex URL validation (query strings, fragments, ports), consider using your language's URL parser instead.

US Phone Number:

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

Matches common US formats: (555) 123-4567, 555-123-4567, 555.123.4567, 5551234567. For international numbers, phone number validation libraries are more appropriate than regex.

For all of these patterns, the best practice is to use them for initial client-side validation and do proper validation server-side using dedicated libraries. Regex catches obviously wrong input; libraries handle the edge cases.