Regex Cheatsheet
How to use this regex cheatsheet
- Browse by category, or search for a keyword.
- Each pattern shows a short description of what it matches.
- Click any pattern to copy it to your clipboard.
Where can I test these patterns?
Use OmniDeck's Regex Tester tool to try any of these patterns against real text and see live matches highlighted.
Do these patterns work the same in every programming language?
Mostly yes for basic syntax, but there are differences between regex "flavors" (JavaScript, PCRE, Python's re module, etc.) for advanced features like lookbehind or named groups — always test in your actual environment.
Why does my pattern match more or less than expected?
Regex is greedy by default (it matches as much as possible) — for shorter, more precise matches, use a non-greedy quantifier like *? or +?, and double check your character classes and anchors.
How backtracking actually decides what a greedy quantifier matches
A greedy quantifier like * or + doesn't simply grab the longest possible match and stop — it works through a process called backtracking that's worth understanding to predict what a pattern will actually match. The engine first attempts to consume as many characters as it possibly can, then, if the overall pattern fails to match with that much consumed, it gives back one character at a time and retries the remaining pattern against each successively shorter possibility, continuing until either the whole pattern matches or every possibility has been exhausted. This backtracking behavior is exactly why greedy and lazy quantifiers can produce meaningfully different results even on identical input — on the text <a><b>, a greedy <.*> matches the entire <a><b> as one span, backtracking only until the very last possible closing bracket makes the whole pattern succeed, while a lazy <.*?> stops at the very first valid match instead, matching only <a>.
Catastrophic backtracking — how a regex can genuinely freeze your application
Certain regex patterns, particularly ones containing nested or overlapping quantifiers like (a+)+ or (a*)*, can trigger a serious, real performance problem called catastrophic backtracking, where the number of ways the engine could try to match a particular string grows exponentially with input length rather than staying linear. Against a carefully crafted input designed to trigger this — often just a moderately long string that almost matches but ultimately fails — matching time can explode from milliseconds into minutes or effectively forever, genuinely freezing an application. This exact vulnerability class, called ReDoS (Regular Expression Denial of Service), is a real, documented security concern specifically for any regex applied to untrusted user input, which is precisely why nested quantifiers on the same repeated character class deserve real, deliberate scrutiny before deploying a pattern to handle input you don't fully control.
Capturing groups versus non-capturing groups — a small syntax difference with a real performance cost
Parentheses in regex create a capturing group by default, meaning the engine specifically remembers and stores whatever text matched inside them, retrievable afterward through numbered backreferences or a match result's groups array. Writing (?:...) instead creates a non-capturing group — it still groups the pattern for applying a quantifier or alternation to the whole group, but the engine doesn't bother tracking or storing what specifically matched inside it. When you genuinely don't need to extract or reference a particular group's matched content afterward — commonly true for a group used purely to apply a quantifier to an alternation, like (?:cat|dog)s — using the non-capturing form is a small but real, measurable performance and memory optimization, and it also keeps a match result's numbered groups list cleaner and easier to reason about by not cluttering it with groups nobody actually needed to capture.
Lookahead and lookbehind — matching based on context without consuming it
Lookahead (?=...) and lookbehind (?<=...) assertions let a pattern require that certain text exists immediately before or after the actual match, without that surrounding context itself becoming part of the matched text or consuming any characters from the overall matching position. This is genuinely useful for patterns like matching a number only when it's immediately followed by a specific currency symbol, without that currency symbol itself being included in the captured match. Negative lookahead (?!...) and negative lookbehind (?<!...) work the same way but require that the specified pattern does NOT appear at that position instead. It's worth knowing that lookbehind support historically arrived later than lookahead in several regex engines (and remains genuinely unsupported in a few older or more limited engines even today), which is exactly why it's worth verifying lookbehind support specifically in your actual target environment before relying on it in production code.
Limitations of this tool
This tool provides a searchable reference of common regex syntax and patterns — it doesn't test a pattern against actual live text (use this site's Regex Tester tool for that instead) and doesn't cover every advanced feature or flavor-specific syntax difference across every regex engine (JavaScript, PCRE, Python's re module, and others each have their own particular quirks and extensions beyond the common core syntax covered here). As the FAQ above notes, always verify a specific pattern's actual behavior in your real target environment, especially for advanced features like lookbehind, named groups, or Unicode property escapes, since flavor-specific support genuinely does vary.