Regex Cheatsheet

A regex cheat sheet with examples — and a live tester

This regex cheat sheet puts every regular expression token one search away — and pairs it with a live tester so you can try a pattern the moment you look it up. Type a pattern, pick your flags, paste a test string, and matches highlight instantly while each capture group is broken out below.

There's nothing to install and no account to create: the whole regular expression reference runs in your browser, so the text you test is never uploaded. No ads, no login wall, no file size limits on your test strings.

Every regex token, grouped with examples

The reference covers the syntax you actually reach for: character classes (\d, \w, \s and custom sets like [a-z]), anchors and boundaries (^, $, \b), quantifiers (*, +, ?, {n,m} and their lazy forms), groups and alternation, lookahead and lookbehind, the flags g i m s u y, and the escapes you need for literal dots and slashes.

Every entry carries a short, concrete example — \bcat\b matches the word 'cat' but not 'category' — so the meaning sticks. Search the regex tokens by symbol or keyword and click any one to copy it.

Test your pattern as you build it

Static cheat sheets can't tell you whether your pattern actually works. The built-in regex tester compiles your expression live, highlights every match in the sample text, and lists the numbered and named capture groups for each one.

Toggle the global, case-insensitive, multiline, dotall, Unicode and sticky flags and watch the results change. If a pattern is invalid you get a plain-English error instead of a silent failure — and seeing a pattern match in real time is the fastest way to learn regex.

Common regex patterns, ready to copy

Some patterns come up again and again — email addresses, URLs, phone numbers, ISO dates, IPv4 addresses, hex colors and strong-password checks. The Common patterns section gives you a vetted version of each: load it straight into the tester to watch it run on example text, or copy it into your code.

They're pragmatic starting points you can adapt rather than one-size-fits-all rules, which is exactly why testing them on your own data matters.

How this compares to regex101.com and regexr.com

regex101.com is the most popular dedicated regex tool on the web — and for good reason. It supports six regex flavors (PCRE, Python re, Golang, Java, .NET, and JavaScript), displays a token-by-token explanation panel, and tracks a match history. If you are debugging a complex production pattern or need to verify that a pattern behaves identically across PHP and Python, regex101 is the right tool for the job. regexr.com offers a similar experience with a public community library of contributed patterns.

This UtiloKit page sits at a different point in the workflow. It combines a token reference table you can search with a live tester on the same screen, optimized for the common situation where you know roughly what you need but can't remember the exact syntax. You land, look up the token, paste a quick test string, and go back to your editor — no tab-switching, no account, no ads. For developers who hit regex101.com dozens of times a day just to recall whether lookbehind uses (?<=…) or (?<!…), having a dedicated searchable reference is measurably faster. Use both: regex101 for deep debugging, this page for quick lookups.

Regex flavors: JavaScript, Python, Java, PCRE and grep

Most regex syntax is portable, but engines differ in the details. The tester here uses JavaScript regex, the same flavor as Node.js and the browser. The Python re module wants raw strings like r"\d+" and names groups (?P<name>…); Java needs doubled backslashes in string literals; PCRE (PHP, and grep -P) is the most feature-complete; and POSIX grep -E has its own escaping quirks.

The flavor table calls out named groups, dotall, case-insensitivity, lookbehind and 'find all' across each engine, so you can move a python regex cheat sheet pattern into JavaScript — or the other way — without surprises.

Greedy vs lazy, and other gotchas

Two things trip up almost everyone. First, quantifiers are greedy: .+ grabs as much as it can, so to match a single HTML tag you usually want the lazy .+? instead. Second, forgetting to escape metacharacters — a bare . matches any character, while \. matches a literal dot, so a price regex needs \d+\.\d{2}.

Keep the cheat sheet open while you work and these stop being surprises.

Private, instant and free

There's nothing to install and no account to create. Every lookup, every match and every copy happens locally in your browser — your patterns and test data never leave your device. Bookmark this regex cheat sheet and reach for it whenever you need to remember a token or sanity-check a pattern.

A brief history of regular expressions

Regular expressions trace their origin to formal language theory. In 1951 the mathematician Stephen Kleene published his work on regular sets — a class of languages that a finite-state machine can recognize — and the algebraic notation he used to describe them became what we now call a regular expression. Kleene's theorem established the equivalence between regular languages and finite automata, giving computer science one of its most enduring theoretical pillars.

The theory became a practical tool in 1968 when Ken Thompson implemented a regex engine inside the Unix line editor ed, and then in the search utility grep, at Bell Labs. Thompson's engine compiled a pattern directly into a non-deterministic finite automaton (NFA), which could be simulated in linear time — a clean engineering translation of Kleene's math. The word grep itself is short for globally search a regular expression and print, and the tool shipped with every Unix system, putting regex in the hands of programmers worldwide.

The Unix ecosystem later produced the POSIX standard, which codified two flavors: Basic Regular Expressions (BRE, used by default in grep and sed) and Extended Regular Expressions (ERE, enabled with grep -E or awk). POSIX ERE added unescaped +, ? and | operators but deliberately left out lookaheads and backreferences. The decisive expansion came with Perl in the 1980s: Perl's regex dialect added non-greedy quantifiers, lookaheads, lookbehinds, named groups and a host of other features. When Philip Hazel extracted this dialect into a standalone C library in 1997 as PCRE (Perl Compatible Regular Expressions), those features became portable — and today PCRE syntax is what most developers mean when they say "regex."

Catastrophic backtracking and ReDoS attacks

Not all regex patterns are equally safe to run on untrusted input. A ReDoS attack (Regular Expression Denial of Service) exploits the way backtracking NFA-based engines explore pattern alternatives. When a pattern contains nested quantifiers — the classic example is (a+)+ — the engine can try exponentially many different ways to match a string before concluding there is no match. On a crafted input such as "aaaaaaaaaaaaaab", the pattern (a+)+b triggers over one million backtracking attempts for 20 repeating characters; doubling the input length roughly squares the number of steps, meaning a sufficiently long string can halt a server thread for seconds or minutes on a single regex evaluation.

Real incidents prove this is not theoretical. In July 2016 Stack Overflow suffered a site-wide outage lasting roughly 34 minutes because a malicious comment containing a long string of spaces triggered a ReDoS vulnerability in the Markdown parser's regex. Cloudflare documented a similar production incident in 2019. The vulnerable pattern structures to watch for are nested quantifiers ((a*)*, (a+)+), overlapping alternation ((a|aa)+), and any combination where two branches of a group can both match the same characters in multiple ways.

Mitigation options include enforcing an input length limit before evaluation, setting a timeout on the regex call, and rewriting patterns to use possessive quantifiers (a++ in PCRE) or atomic groups ((?>a+)) which discard backtracking information once a sub-expression has matched. The most complete solution for security-critical contexts is the RE2 engine — developed at Google and available for Go, C++ and Python — which compiles patterns to a DFA that guarantees O(n) linear time in the length of the input, making catastrophic backtracking structurally impossible. The trade-off is that RE2 deliberately rejects backreferences and some lookaround assertions, the very features that cause exponential blowup.

Lookaheads, lookbehinds, and non-capturing groups

Lookaround assertions let you condition a match on what surrounds it without consuming those surrounding characters. A positive lookahead (?=…) matches a position only when the sub-expression inside it matches to the right — \d+(?= dollars) matches the number in "50 dollars" but does not include the word dollars in the match. Its counterpart, the negative lookahead (?!…), matches a position only when the following text does not match — \b(?!un)\w+ matches words that do not begin with the prefix un. Lookbehinds work the same way but look to the left: the positive lookbehind (?<=\$)\d+ matches digits that are immediately preceded by a dollar sign, and the negative lookbehind (?<!\d)\d+ matches a number that is not preceded by another digit. Because lookarounds test a position rather than consuming text, you can stack several of them on the same point in the string without disturbing the matched substring.

Non-capturing groups (?:…) let you apply a quantifier or alternation to a sub-expression without creating a numbered capture slot. This matters for performance — every capturing group allocates storage in the match result, and in a hot loop over millions of strings that cost adds up. It also prevents accidental numbering shifts: if you add (?:https|ftp) to an existing pattern, the groups you were already extracting keep their positions. Non-capturing groups are best practice any time you need to group purely for structure, not for extraction.

Named capturing groups carry this further by giving each group a label you can use in code. The JavaScript and PCRE syntax is (?<name>…), while Python uses (?P<name>…). A date pattern such as (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2}) lets you write match.groups.year instead of match[1], making the intent clear and removing the fragility of positional indexing. Named groups are also available as named backreferences (\k<name> in JavaScript, (?P=name) in Python), which is useful for patterns that need to assert a repeated value — for example matching an HTML open tag and verifying its close tag carries the same element name.

Regex flavors and cross-language differences

The core token set — character classes, quantifiers, anchors, groups — is broadly consistent across languages, but meaningful differences accumulate at the edges. JavaScript shipped without lookbehind support until ES2018, which means older polyfill code often works around it; the u flag enables proper Unicode code-point matching (fixing . for astral-plane characters like emoji), the s (dotAll) flag makes . match newlines, and named groups via (?<name>…) also arrived in ES2018. JavaScript has no built-in compiled-pattern object: RegExp instances are compiled on construction, so creating the same literal inside a loop re-compiles it on every iteration — a common performance mistake. Python's re module closely follows PCRE syntax but uses (?P<name>…) for named groups, (?P=name) for named backreferences, and the re.VERBOSE flag (re.X) which strips unescaped whitespace from the pattern and allows # comments inline — invaluable for documenting complex patterns. Always pass the pattern as a raw string (r"\d+") to avoid Python interpreting the backslash before Python sees it.

Java's java.util.regex package requires that you double every backslash in a string literal because \ is Java's string escape character: the regex \d+ must be written "\\d+" in source code. Flags are applied either via constructor constants (Pattern.CASE_INSENSITIVE, Pattern.DOTALL) or inline as (?i) inside the pattern. Pre-compiling with Pattern.compile() is important for production code since the JVM does not cache patterns automatically. .NET offers the most feature-rich built-in flavor: it supports atomic groups via (?>…), possessive quantifiers, and uniquely supports balancing groups — a syntax extension ((?<open-close>)) that can track nesting depth, allowing a single .NET regex to match balanced parentheses, something strictly outside the power of regular languages. Go's regexp package uses the RE2 engine by design: backreferences and lookaheads are rejected at compile time, and Unicode categories are available via \p{L} (any Unicode letter). The trade-off is safety: Go regex is guaranteed O(n) and cannot be made to backtrack catastrophically.

POSIX ERE — the flavor used by grep -E, awk and many Unix command-line tools — lacks the \d, \w and \s shorthand classes entirely; you must write [0-9] and [a-zA-Z0-9_] instead. There are no lookaheads, no non-capturing groups, no backreferences in ERE (BRE adds \1 but with different escaping rules), and alternation with | does not require escaping. When porting a JavaScript or Python pattern to a shell script it is common to discover that half the tokens silently mean something different — or are simply unsupported. The flavor table on this page captures the most impactful differences so you can translate patterns without surprises.