Regular Expressions: A Practical Guide

Regular expressions have a reputation for being unreadable, and the reputation is partly earned — but almost every confusing behaviour becomes predictable once you understand one mechanism: backtracking. This guide starts there, because everything else follows from it.

How an engine actually matches

Most regex engines you will use — JavaScript, Python, Perl, PCRE, Java — are backtracking engines. The procedure is:

1. Start at position 0 of the input.
2. Attempt to match the pattern, consuming characters element by element.
3. If an element fails, backtrack: return to the most recent choice point (a quantifier or alternation) and try the next option.
4. If all options at this start position are exhausted, advance the start position by one and repeat.
5. Stop at the first successful match.

Result: matching is leftmost and earliest, and among alternatives at the same position, the engine prefers whatever its quantifier rules say first. That preference is where greediness comes from, and the exhaustion of alternatives is where the performance cliff comes from.

Greedy versus lazy

Quantifiers are greedy by default: they consume as much as possible, then give back only when the remainder of the pattern demands it. Adding ? makes them lazy: consume as little as possible, expand only when forced.

Text:  <h1>Title</h1> and <p>Body</p>

<.*>    greedy  →  "<h1>Title</h1> and <p>Body</p>"
                  one match, spanning from the first < to the last >

<.*?>   lazy    →  "<h1>", "</h1>", "<p>", "</p>"
                  four matches

Neither is inherently right — they answer different questions. But notice that both rely on . being able to cross the closing >. The better answer for "the contents of a tag" excludes the delimiter from the character class entirely, so overrunning is structurally impossible:

<[^>]*>  →  "<h1>", "</h1>", "<p>", "</p>"

This is both correct AND faster: the engine never has to backtrack,
because the character class cannot consume the terminating >.

The general principle: prefer a precise negated character class over a lazy quantifier. It expresses intent more accurately and it eliminates backtracking.

Catastrophic backtracking

This is the one that causes production incidents, and it deserves real attention.

When a pattern contains nested quantifiers — a quantifier applied to a group that itself contains a quantifier or a repeating alternation — the number of ways to split the input grows exponentially. On a successful match the engine usually finds an answer quickly. On a failure, it must exhaust every combination, and that can take exponential time.

/(a+)+$/.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaaX")
// Fails — but first tries every possible way to partition 30 a's
// among one or more groups of one or more a's.
// On a modern browser this can take minutes.

The classic shapes that trigger it:

(a+)+              nested quantifier
^(a|a)*$           ambiguous alternation inside a quantifier
(a|aa)+            overlapping alternatives
(\s*\w+)*          quantifier over a group containing a quantifier

Why this matters beyond slowness: it is a genuine denial-of-service vector. If your server runs a user-supplied regex, or matches user-supplied input against a pattern with nested quantifiers, an attacker can send a short string that pins a CPU core. This is ReDoS and it has its own CVE category.

Defences, in order of preference:

1. Rewrite the pattern. Nested quantifiers are almost always unnecessary. Replace with a bounded or negated class: (a+)+ → a+.
2. Use a linear-time engine. RE2 (available in Go, and via bindings elsewhere) guarantees matching time linear in input length, because it does not backtrack at all. The trade-off is no backreferences or lookaround.
3. Impose a timeout or run matching in a subprocess with a CPU limit, if you must accept patterns from users.
4. Never match user input against user-supplied patterns on a request thread.

Anchors and validation

^ matches the start of the string and $ the end — unless the multiline flag m is set, in which case they match the start and end of any line.

This distinction is the source of a common security bug in input validation:

/\d+/            "matches" abc123def — digits exist somewhere inside
/^\d+$/          only matches a string consisting entirely of digits  ✓
/^\d+$/m         matches any single line that is entirely digits

When validating, always anchor both ends. An unanchored validation pattern accepts anything containing a valid substring.

One more subtlety: in several engines $ also matches immediately before a trailing newline. So /^\d+$/ accepts "123\n". If that matters, use \\z (Java, PCRE, Ruby) or trim the input first.

Groups, capture and naming

Parentheses do two jobs at once: grouping and capturing. If you only need grouping, use (?:…) — it avoids allocating a capture slot and keeps indices clean.

(https?|ftp)://([^/]+)(/.*)?
  1 = scheme, 2 = host, 3 = path

(?:(https?|ftp)://)?([^/]+)
  1 = scheme (undefined if absent), 2 = host

Named groups make anything non-trivial readable, and most modern languages support them:

const re = /(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})/;
const { year, month, day } = re.exec("2026-09-18").groups;

Backreferences let you match a repeat of an earlier capture: (\\w+)\\s+\\1 finds a duplicated word. Be aware that backreferences make a pattern non-regular in the formal sense, which is one reason linear-time engines do not support them.

Lookaround

Lookaround asserts a condition without consuming characters — which is what makes it so useful for insertion and validation rules.

\\d+(?= dollars)     lookahead:  digits followed by " dollars"
(?<=\\$)\\d+          lookbehind: digits preceded by "$"
\\d+(?! dollars)     negative lookahead: digits NOT followed by " dollars"
(?<!\\$)\\d+          negative lookbehind

A practical use — inserting thousands separators without matching the boundaries:

"1000000".replace(/\\B(?=(\\d{3})+(?!\\d))/g, ",")
// "1,000,000"

Complexity warning: a quantifier inside a lookahead can itself cause backtracking problems. And browser support for lookbehind arrived later than for lookahead — check your target environments if you support older Safari.

A library of correct patterns

Email (pragmatic — confirm by sending mail, not by regex)
\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}\\b

ISO-8601 UTC timestamp
^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d+)?(?:Z|[+-]\\d{2}:\\d{2})$

Semantic version
^v?(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-[\\w.-]+)?(?:\\+[\\w.-]+)?$

IPv4 with range validation
^(?:(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]?\\d)\\.){3}(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]?\\d)$

URL slug
^[a-z0-9]+(?:-[a-z0-9]+)*$

Hex colour
^#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{6})$

Strong-ish password (length + character classes)
^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[^\\w\\s]).{12,}$

On that last one: length matters far more than composition rules. A 12-character password with no special characters is vastly stronger than an 8-character one with all four classes. Composition rules mostly annoy users; length is what buys entropy.

When not to use a regex

HTML and XML

HTML is not a regular language — tags nest arbitrarily, and no regex can correctly handle that. Every attempt works on your sample input and fails on real-world markup. Use a parser: DOMParser in the browser, BeautifulSoup in Python, cheerio in Node.

URLs and email addresses

Both have formal grammars with edge cases you will not think of. Every language's standard library has a correct parser. Use it.

Anything with recursion

Nested structures — JSON, mathematical expressions, source code — exceed what a regex can express. Some engines support recursive patterns as an extension, but if you need recursion you need a parser.

The dividing line: regex is superb for extracting, validating and rewriting flat text, and wrong for anything with nested structure.

Debugging tip

Test incrementally against the specific string that is failing, not against your mental model. Build the pattern up one element at a time and check after each addition — the element where it breaks is almost never the one you suspected. Our Regex Tester highlights matches live so you can see exactly where the engine stops matching.