Back to All Cheatsheet Libraries
cheatsheets
A full syntax token reference, ready-to-use patterns for common formats, and an incremental pattern-building workflow.
Total Tokens: 0
| Category | Token | Matches |
|---|---|---|
| Anchors | ^ | Start of the string (or line, in multiline mode). |
| Anchors | $ | End of the string (or line, in multiline mode). |
| Anchors | \b | A word boundary — the edge between a word character and a non-word character. |
| Character Classes | . | Any character except a newline (unless the dotall/s flag is set). |
| Character Classes | \d | Any digit, equivalent to [0-9]. |
| Character Classes | \w | Any word character — letters, digits, and underscore. |
| Character Classes | \s | Any whitespace character — space, tab, newline. |
| Character Classes | [abc] | Any one character in the set — a, b, or c. |
| Character Classes | [^abc] | Any one character NOT in the set. |
| Quantifiers | * | Zero or more of the preceding token. |
| Quantifiers | + | One or more of the preceding token. |
| Quantifiers | ? | Zero or one of the preceding token — makes it optional. |
| Quantifiers | {2,4} | Between 2 and 4 repetitions of the preceding token. |
| Groups | (abc) | A capturing group — the matched text is retrievable separately afterward. |
| Groups | (?:abc) | A non-capturing group — groups for alternation/quantifying without creating a capture. |
| Groups | (?<name>abc) | A named capturing group, retrievable by name instead of index. |
| Lookarounds | (?=abc) | Positive lookahead — matches a position only if followed by abc, without consuming it. |
| Lookarounds | (?!abc) | Negative lookahead — matches a position only if NOT followed by abc. |
| Lookarounds | (?<=abc) | Positive lookbehind — matches a position only if preceded by abc. |
| Alternation | cat|dog | Either "cat" or "dog". |
Ready-to-Use Patterns
| Matches | Pattern |
|---|---|
| Email address (simple) | ^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$ |
| URL (http/https) | https?:\/\/[^\s]+ |
| Integer (optionally negative) | ^-?\d+$ |
| Hex color code | ^#([0-9a-fA-F]{3}){1,2}$ |
| IPv4 address (simple) | ^(\d{1,3}\.){3}\d{1,3}$ |
| Whitespace-trimmed line | ^\s+|\s+$ |
| Digits with thousands separator | \B(?=(\d{3})+(?!\d)) |
Common Flags
i
g
m
s
1
Test against real sample data, not one hand-picked example
Include edge cases the pattern needs to reject, not just ones it needs to match — a tool like regex101.com shows both in real time.
2
Build it in small pieces
Get the core shape matching first, then add anchors, then add edge-case handling — debugging one broken 80-character pattern is much harder than debugging one added piece at a time.
3
Comment complex patterns
Most engines support an extended/verbose mode (x flag) that ignores whitespace and allows inline comments — makes a dense pattern reviewable months later.
4
Watch for catastrophic backtracking
Nested quantifiers like (a+)+ can make matching time explode on certain inputs — a real, exploitable denial-of-service class known as ReDoS.
Quick Tips
Don't write your own email regex from scratch
The full RFC 5322 spec is notoriously complex — a simple pattern plus an actual send-a-verification-email check is more reliable than chasing perfect regex validation.
Greedy vs. lazy matching
.* is greedy (matches as much as possible); .*? is lazy (matches as little as possible) — the difference matters a lot when matching between two delimiters. Regex isn't the right tool for nested structures
Parsing HTML/JSON/nested brackets with regex breaks on edge cases — reach for a real parser once the structure has arbitrary nesting.