Regex cheatsheet: one syntax, seven dialects

Which engine actually runs your pattern

“Regex” names a family, not a language. The pattern you polished on regex101 ran on PCRE2 unless you touched the flavor picker; in production the same characters land in a different engine with different rules. Before any syntax, know which one you are talking to:

The family column decides more than the feature lists do. Linear-automaton engines (Go, Rust, RE2) refuse backreferences and lookaround outright, and in exchange they can never blow up on malicious input. Backtracking engines take the full syntax and can. MySQL is the quiet surprise in the table: 8.0.4 swapped Henry Spencer’s engine for ICU, so patterns that failed for years on old servers work now, and a few old ones changed meaning.

Characters and classes

Anchors and boundaries

The validation traps live in this table. Ruby first: because ^ and $ anchor lines, the input alice\ndrop everything passes a check like /^[a-z]+$/, its first line matches and that is enough. The Rails security guide has told people to anchor validations with \A and \z for over a decade, and the bug still ships. Python has a smaller version of the same hole: re.match(r'^\d+$', '42\n') succeeds because $ tolerates one trailing newline. When the exact end matters, use \Z (Python) or \z (everywhere else), or re.fullmatch, which tolerates nothing.

Quantifiers

One structural rule matters more than all the syntax: a quantifier wrapped around another quantifier, (a+)+ and its relatives, is how a pattern turns into a denial-of-service bug. That mechanism took down Cloudflare and Stack Overflow and has its own guide here; our ReDoS checker finds the ambiguous part of a pattern and times it against a generated attack string, in your tab.

Groups and lookaround

Flags

The flavor matrix

The table we reach for every time a pattern moves between languages. Versions are load-bearing here, which is exactly what the flavor-blind cheatsheets leave out.

.NET deserves its footnote: Unicode \d and \w by default, lookbehind with no length restriction at all, a match timeout since 2012, and a NonBacktracking mode since .NET 7. It is the quiet feature leader of the backtracking family. On the other end, Perl allowed variable-length lookbehind in 5.30 with the same 255-character cap PCRE2 later copied.

Six bugs that ship every week

1. A JavaScript /g regex is stateful. re.test(s) and re.exec(s) advance re.lastIndex past each match, so a reused global regex answers true, false, true, false on the same string. Drop the g when you only test, or use s.match(re), which resets.
2. Java’s matches() anchors silently. "abc".matches("b") is false: the method demands a full-string match, as if \A…\z were wrapped around your pattern. Searching is Matcher.find(). Half of Java’s “regex doesn’t work” questions are this.
3. Python’s re.match is neither search nor fullmatch. It anchors at the start and nowhere else. re.search scans, re.fullmatch (since 3.4) demands everything. Picking the wrong one of the three fails quietly in both directions.
4. String literals eat backslashes. In MySQL, REGEXP '\d+' sends d+ to the engine, because the string parser consumes the backslash first; you need '\\d+'. Same story in Java strings and JSON. Python raw strings and JS regex literals exist to end this, use them.
5. The shell gets the pattern before grep does. Unquoted, grep 3.14 file happily reports 3714 and 3x14, and a stray * becomes a glob before grep ever runs. Single-quote every pattern and escape the dot: grep '3\.14'.
6. The pattern is fine, the text is not. Text pasted from Word, PDFs or AI chats carries no-break spaces and zero-width characters that render exactly like the characters your pattern expects, and an ASCII \s or a literal space will not match them. Our invisible character detector names every such character in a paste, and the guide to invisible Unicode covers where they come from.

Regex vs Unicode

Everything above the ASCII line is where cheatsheets usually stop and bugs usually start. The default \w in JavaScript, Java and PCRE is [A-Za-z0-9_], nothing else. An é is a non-word character to these engines, which produces genuinely strange boundaries: /\bcafé\b/.test('café') is false, because after the é there is no word/non-word transition left to anchor on. The match fails against the exact string it was written for.

In JavaScript the honest fix is the u flag plus property classes: (?<!\p{L})café(?!\p{L}) is a Unicode-aware word boundary, spelled by hand, since u upgrades many things but never \b. Python 3 needs none of this, its \w and \b are Unicode-aware unless you ask for re.ASCII.

Case-insensitivity has the same ceiling. The i flag performs simple case folding, one code point to one code point, and German ß uppercases to the two-character SS, so /straße/i does not match STRASSE in any mainstream engine. The folding your language’s toUpperCase() does is the full version; regex engines deliberately run the cheaper one. The Kelvin sign K (U+212A) shows the opposite edge: /k/iu matches it in JavaScript, /k/i without the flag does not.

Patterns you can defend

Copy-paste patterns are where cheatsheets quietly hand you liabilities, so each of these comes with its terms and conditions.

• Trailing whitespace: [ \t]+$ with the m flag, for editor find-and-replace. On a server, against user input, prefer trimEnd(): the innocent-looking anchored form is quadratic on adversarial input and once took Stack Overflow down for 34 minutes.
• Email: the one browsers use for <input type="email">, from the WHATWG HTML spec: ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$. The spec calls it a willful violation of RFC 5322, on purpose: the full RFC admits addresses no provider issues. No nested quantifiers, no backtracking ambiguity, and every browser agrees with you.
• UUID: ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ with i. Version- and variant-pinned forms, plus what the digits mean, are on our UUID generator page.
• IPv4: \d{1,3} per octet accepts 999.0.0.1. The honest octet is an alternation: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])$.
• ISO date: ^\d{4}-\d{2}-\d{2}$ checks the shape and nothing more; 2026-02-30 passes. Calendar validity needs a date parser, a regex cannot count the days of February.
• Semver: do not write your own; the semver spec publishes an official regex in its FAQ, prerelease and build-metadata edge cases included. What the ^ and ~ in package.json do with those versions is a range language on top, not part of the regex.

Things that only look like regex

Two pattern languages sit right next to regex on every project and share just enough syntax to mislead. .gitignore speaks glob: * stops at slashes, ** crosses them, a leading ! renegotiates, and there are no quantifiers or groups at all, build.{js,map} means nothing to git. Our gitignore tester shows which rule catches which path and why. Cron expressions are the other neighbour: */5 * * * * borrows the star and nothing else, five fields with their own grammar, decoded by the cron expression parser.

And the classic: HTML. The 2009 Stack Overflow answer about parsing HTML with regex, the one that dissolves into Zalgo text halfway through, is a joke with a correct core. Nesting is not expressible in a regular language, so a regex can slice a known, constrained shape out of one tag on one line, and it cannot parse arbitrary markup. In a browser or Node, DOMParser and friends are one line; the moment a second angle bracket appears inside an attribute, they win.

Keep a cheatsheet for the tokens, but memorise the flavor matrix. The tokens are the easy 90 percent. Every regex story that ends in a postmortem starts in the other 10.

Regex questions the tables don’t answer