Regex starters, one pattern per page
Twenty-two pattern pieces for developers and data wranglers who meet regular expressions constantly and can't read them: literal text as the pattern you already know, the dot as any one character, character classes as the menu, ranges and the caret, the shorthands, anchors as fence posts, quantifiers as how many, greediness and the lazy question mark, alternation as either-or, groups for fencing and capturing, backreferences, lookahead and lookbehind as peeking without eating, flags, word boundaries, escaping as the escape hatch, the email that matches everything, search versus validation, replacing with capture groups, patterns you already know deconstructed, debugging a pattern bit by bit, one pattern per page.
A diagram, the classic trap, and one thing to go try this week. That's a page.
Regex starters, one pattern per page
Twenty-two pattern pieces for developers and data wranglers who meet regular expressions constantly and can't read them: literal text as the pattern you already know, the dot as any one character, character classes as the menu, ranges and the caret, the shorthands, anchors as fence posts, quantifiers as how many, greediness and the lazy question mark, alternation as either-or, groups for fencing and capturing, backreferences, lookahead and lookbehind as peeking without eating, flags, word boundaries, escaping as the escape hatch, the email that matches everything, search versus validation, replacing with capture groups, patterns you already know deconstructed, debugging a pattern bit by bit, one pattern per page.
Set in Space Grotesk, Inter and JetBrains Mono (SIL Open Font License).
Syntax definitions checked against MDN Web Docs' regular expression pages, the Open Group Base Specifications Issue 7 (POSIX, Section 9), and the PCRE2 and ECMAScript specification documentation. Engine differences (POSIX versus PCRE versus ECMAScript) are cited as the documents state them. Practice claims via PubMed (16719566, 31311973); teaching conventions are named as conventions. None of these organisations is affiliated with or endorses this book.
General information only. Regular expression behaviour varies between engines, tools and flags; test in the engine you actually use. Not advice for your specific system.
Your purchase is for personal use only. You do not have redistribution rights: please do not share, resell, or republish this book or its pages.
© 2026 Steve Hodgkiss. All rights reserved. Personal use only; no redistribution rights.
Edition 1.0 · stevehodgkiss.net
Contents
Reading a pattern
A pattern is steps, most of it is plain text, and the dot is one slot.
- 01A pattern is a picture of text
- 02The dot is any one thing
A regular expression is a pattern describing text by its shape rather than by its exact spelling; MDN Web Docs defines it as patterns used to match character combinations in strings. That learning one piece per page, with a pattern tester, is teaching convention supported by studies of distributed practice (PubMed 16719566) and between-session consolidation (PubMed 31311973), not a measurement about regex specifically.
A pattern is a picture of text
Let's say someone sends you a pattern that looks like keyboard damage, and you paste it in anyway, because that's what everybody does.
A pattern isn't spelling, it's a shape. c.t is a c, then any one character, then a t: cat, cot, cut. Read left to right, a pattern is just steps. Copied without reading, it's a coin flip, and when it eats the wrong text you won't know why.
It's steps, not noise.
Open regex101.com, type c.t in the pattern box, and cat, cot, scotch in the test box. Watch which light up.
MDN Web Docs documents the dot as matching any single character except line terminators, and the dotall flag that changes this; the Open Group Base Specifications Issue 7, Section 9.8.3 defines the period as matching any character in the supported character set. That checking what the dot does in your engine is teaching convention, not a measurement.
The dot is any one thing
Let's say the find worked for weeks, then one day the dot matched ten things, and nothing had changed.
The dot is one slot. In o.r, it eats exactly one character, of any kind. MDN: any single character except line terminators, unless the s flag is on. String several dots together and they'll match from here to the end of the line.
One dot, one character.
In a tester, run a.b against acb and ab. Then a..b. Two dots is two slots.
The Open Group Base Specifications Issue 7, Section 9.8.2 defines anchors as matching a position between characters rather than a character itself; MDN Web Docs documents the start and end anchors and the multiline flag.
Anchors are fence posts
Let's say error matched 41 times and 12 of them were inside other words, and the count went to the boss.
The caret and dollar are fence posts. They don't eat a character, they mark a position: start of line, end of line. With both posts, the match must be the whole line, nothing more, nothing less. People expect a visible character and find nothing in the match. The post is a claim about where, and it's zero-width.
The posts claim positions. They eat nothing.
Run ^log: with the m flag on against a two-line sample. Then without it. Same pattern, different fence.
The working toolkit
The everyday hazards and the everyday payoffs: flags, the great traps, reordering text, and taking patterns apart.
- 01The email that matches everything
- 02Debug a pattern bit by bit
That the famous permissive email pattern matches nearly everything follows from the grammar's permissiveness; MDN Web Docs recommends proper validation over regex for form data. Stated as documentation guidance, not measured here.
The email that matches everything
Let's say you pasted the famous email pattern into your form, felt secure, and the junk signups kept coming.
The giant email pattern matches nearly everything, because the real rules allow nearly everything. MDN's own guidance: validate properly, server-side, rather than trust a pattern for form data. A green tick from a permissive pattern is validator theatre. The user typed a shape, and shapes don't have mailboxes.
A pattern checks shape. It can't check the mailbox exists.
Paste the longest email pattern you can find into a tester and feed it clearly-junk-at-example.com. Watch it pass.
That breaking a pattern into pieces and testing each incrementally is standard practice advice; MDN Web Docs recommends building patterns incrementally. The learning-method claims are the general practice studies (PubMed 16719566, 31311973); regex specificity is convention.
Debug a pattern bit by bit
Let's say the pattern matched nothing, you changed three things at once, and now you have two broken patterns.
Debug one piece at a time: cut back to the head that matches, add one piece, test, repeat. MDN recommends building patterns incrementally, and the practice research agrees: little and often beats one long Friday fight. The failure is always one piece.
Never debug a whole pattern. Debug one piece.
Take your oldest broken pattern, cut it to the first two pieces, then add one piece at a time until it breaks.