Regex Explained: How to Read Any Regular Expression

A regular expression is a tiny program. Not a magic string, not a password you copy off Stack Overflow and hope for. It is a program whose only job is to describe a shape in text, and whose only output is: does this shape occur here, and if so, where does it start and stop. Every language ships one. Python calls it re, JavaScript bakes it into the syntax with slashes, Go calls it regexp. The dialects differ at the edges and agree in the middle, so reading skill transfers.

I think the fear comes from one bad habit: people read a pattern as a single blob and try to recognize it, the way you recognize a word. That never works. A regex is read the way the engine reads it, one piece at a time, left to right. Do that and ^\d{4}-\d{2}-\d{2}$ stops being noise and starts being a sentence.

Read it left to right, asking three questions

At every step through a pattern, the engine is answering some combination of three questions. Where am I allowed to be? Which characters are allowed here? How many of them do I take? That is genuinely most of it.

Start with the smallest possible pattern. A literal matches itself, which is exactly your editor's find box.^[1]

import re

text = "the cat scattered the cathedral"

# A literal matches itself, anywhere it occurs.
re.findall(r"cat", text)
# ['cat', 'cat', 'cat']   <- also inside "scattered" and "cathedral"

# \b is a word boundary: the seam between a word character and a non-word one.
re.findall(r"\bcat\b", text)
# ['cat']

That second pattern is the whole idea in miniature. \b matches the empty string, but only at the boundary between a word character and a non-word character.^[1] It consumes nothing. It just refuses to be anywhere else. Anchors are constraints on position, not on content, and once that clicks a lot of patterns get easier.

Build one up, a piece at a time

Character classes come next. A class in square brackets means “any one character from this set”, and the common ones get shorthands: \d for a digit, \w for a word character (letters, digits, underscore), \s for whitespace.^[1] Then quantifiers say how many. Then anchors pin the whole thing down.

import re

# Character class + fixed count.
re.findall(r"[0-9]{3}-[0-9]{4}", "call 555-0142 or 555-9981")
# ['555-0142', '555-9981']

# Same idea with the \d shorthand, anchored to the whole string.
re.fullmatch(r"\d{4}-\d{2}-\d{2}", "2026-08-16")
# <re.Match object; span=(0, 10), match='2026-08-16'>

# Alternation: try the left side, then the right.
re.findall(r"ERROR|FATAL", "INFO ok\nERROR disk\nFATAL bus")
# ['ERROR', 'FATAL']

Notice the date pattern says nothing about whether the date is real. It matches 9999-99-99 happily. That is not a flaw, it is the deal: a regex checks shape, and your code checks meaning. Every time I have seen someone try to validate a date range inside the pattern, the pattern got twice as long and still needed the check afterward.

Groups are the part you actually use

Parentheses do two jobs at once. They group things so a quantifier can apply to the whole run, and they capture, meaning the engine hands that substring back to you. Numbered groups start at 1 and count opening parentheses left to right.^[1] Named groups do the same thing without the counting.

import re

m = re.search(r"(\d{4})-(\d{2})-(\d{2})", "released 2026-08-16 ok")
m.groups()      # ('2026', '08', '16')
m.group(1)      # '2026'

# Named captures: same pattern, readable at the call site.
m = re.search(r"(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})",
              "released 2026-08-16 ok")
m.group("year")  # '2026'
m.groupdict()    # {'year': '2026', 'month': '08', 'day': '16'}

Use named groups. Numbered groups are fine when you write them and hostile six months later when someone inserts a parenthesis in the middle and every index after it shifts by one. The naming syntax is one of the small places where Python went its own way, which is the sort of difference worth knowing if you move between languages, as in this side-by-side comparison of Python and Java syntax.

Greedy versus lazy, the first real fork in the road

Here is where people start losing arguments with their own patterns. Quantifiers are greedy by default: they match as much text as possible, then give characters back one at a time only when the rest of the pattern fails. The Python docs use the perfect example.^[1]

import re

text = "<a> b <c>"

re.findall(r"<.*>", text)     # greedy: takes everything it can
# ['<a> b <c>']

re.findall(r"<.*?>", text)    # lazy: takes as little as it can
# ['<a>', '<c>']

re.findall(r"<[^>]*>", text)  # better: no choice to make at all
# ['<a>', '<c>']

Read the greedy case the way the engine does. .* runs to the end of the string. Then the engine needs a >, has nothing left, and walks backward until it finds one. The last > in the string is the closing bracket of <c>, so the match spans the whole line. Adding a question mark reverses the direction: start at zero characters and grow only when forced.

The failure mode with a body count

Now the thing that actually matters, and the reason serious codebases have opinions about regex. Most engines you use daily, including Python, JavaScript, Java, .NET and PCRE, are backtracking engines. They try one alternative at a time and rewind when it fails. That is what makes backreferences and look-around possible. It is also what makes them detonate.

The classic trigger is a quantifier inside a quantifier. OWASP lists (a+)+$ first among its evil regex examples.^[4] Ask why and the answer is combinatorics: for the input aaaaX, OWASP counts 16 distinct paths through the two quantifiers, every one of which fails on the X. That is 2ⁿ, not the eight ways of splitting the run itself, because the outer + re-enters for each split. Push it to sixteen letters and the count is 65,536, and it doubles for each additional character.^[4]

I ran it, because a number you have not seen with your own eyes is just a rumor.

Node.js gave me 44 seconds on that same 31-character input, so this is not a Python problem. And notice the last stat: ^a+$ matches exactly the same set of strings as ^(a+)+$, in microseconds, on an input 300 times longer. The nesting bought nothing. It never does. That is the tell.

If that still feels academic, it has a receipt. On July 2, 2019, Cloudflare deployed a new firewall rule containing the subexpression .*.*=.*. Two .* in a row is a milder relative of the same disease: two greedy runs competing for the same characters, quadratic rather than exponential. Quadratic is enough. Their own step count fits n² + 7n + 15 exactly. Their own postmortem walks through it, and notes that matching x= followed by twenty x characters takes 555 steps.^[5]

Go and Rust just refuse

Here is the part I find genuinely elegant. Google's RE2, which is the engine behind Go's regexp package, has been in production since 2006 with an explicit goal of handling patterns from untrusted users. Its README states the guarantee plainly: match time is linear in the length of the input string.^[2] The Rust regex crate makes the same promise in complexity notation, worst case O(m * n) where m is the size of the pattern and n the size of the text.^[3]

Both pay for it the same way. Instead of trying alternatives one at a time and rewinding, they track every possible position at once, which means the work per input character is bounded no matter how the pattern is shaped. And both drop the features that make that impossible. RE2 puts it as a matter of principle: it does not support constructs for which only backtracking solutions are known to exist, so backreferences and look-around assertions are not supported.^[2] Rust says the same thing in its opening paragraph.^[3]

That is a genuine tradeoff, not a free lunch. If you need to match repeated words with (\w+) \1, RE2 cannot help you, and people hit that wall and get annoyed. My honest read after years of this: the wall is a feature. If your pattern needs a backreference, you have probably wandered out of the territory regular expressions are good at, and the language forcing you to notice is doing you a favor.

Where to stop

Two places deserve a hard no, and both are famous for a reason.

Parsing HTML. HTML nests, and a regular expression has no memory of how deep it currently is, so it cannot match an opening tag to its own closing tag across arbitrary nesting. Use a parser for structure. A regex is still the right tool for finding an ISO date inside the text a parser hands you.

Validating email addresses to the RFC. RFC 5322 permits comments, folded whitespace and quoted strings inside an address, so a fully conformant pattern is thousands of characters long and matches things no mail provider will accept. The WHATWG HTML Standard, which defines what a browser does for <input type="email">, declined the whole problem. Its spec text calls its own simpler definition a “willful violation of RFC 5322”, on the grounds that the real grammar is simultaneously too strict before the at sign, too vague after it, and too lax overall to be of practical use.^[6] When the HTML specification says the standard is unusable and ships a shorter pattern instead, take the hint and copy theirs.

So: read left to right, name your groups, prefer a negated class over a lazy quantifier, and treat a quantifier inside a quantifier as a bug until proven otherwise. If the text you are matching comes from strangers, run it on an engine that cannot explode. Regex is not scary. It is just a language nobody bothered to teach you the grammar of, and the grammar takes about a page.