How to test regex patterns

Regex is a superpower until it isn’t. A pattern that looks right can match too much, too little, or nothing at all, and the error messages your language’s regex engine gives are usually either silence (zero matches) or catastrophic backtracking that hangs your process. The only reliable way to get regex right is to test it against a deliberate set of inputs: strings that should match, strings that should not, and the tricky edge cases at the boundaries. Then you examine the capture groups and verify they’re grabbing what you actually want. This guide covers how to build a test matrix, the difference between greedy and lazy quantifiers, anchors and word boundaries, capture groups, the most useful flags, and how to spot catastrophic backtracking before it reaches production.

Start with test cases, not the pattern

Before writing a regex, write down the inputs it must match, the inputs it must reject, and the edge cases. For an email validator, that’s obvious emails, emails with plus-addressing, international domains, leading/trailing whitespace, empty strings, and the classic “a@b.c” that RFC says is valid but intuition rejects. Build the pattern against these cases iteratively; don’t try to write it in one shot from memory.

Should match:       alice@example.com
                    bob+tag@sub.example.co.uk
                    c@d.ef
Should NOT match:   @example.com
                    alice@
                    alice@@example.com
                    alice example.com
                    (empty)

Anchors: start, end, word boundary

^ anchors to the start of the string (or line, with the m flag).$ anchors to the end. Without anchors, \d+ matches digits anywhere inside the string, not the whole string. \b is a word boundary: it matches the transition between a word character and a non-word character. \bcat\b matches the word “cat” but not “catalog.”

^d+$      entire string is digits
d+        contains digits somewhere
cat    the standalone word "cat"
cat      "cat" at the start of a word (matches "catalog" too)

Greedy versus lazy quantifiers

By default, quantifiers are greedy—they match as much as possible. <.+> against <a>text</a> matches the entire string because .+ eats everything then backtracks. The lazy form <.+?> stops at the first >. Quantifiers with ?appended become lazy: *?, +?, {2,5}?.

Input: <a>text</a>
<.+>     matches  <a>text</a>          (greedy, whole string)
<.+?>    matches  <a>                  (lazy, stops at first >)
<[^>]+>  matches  <a>                  (character class, no backtrack)

Character classes

Square brackets define a set of acceptable characters. [abc] matches a, b, or c. [a-z] matches any lowercase letter. [^abc] (with caret inside) means “anything except a, b, c.” Common shorthand: \dis [0-9], \w is [A-Za-z0-9_], \s is whitespace, and capital versions (\D, \W, \S) are their complements.

Capture groups and back-references

Parentheses create numbered capture groups. (\d+)-(\d+) against 123-456 captures “123” in group 1 and “456” in group 2. Back-references reuse a captured value: (\w+)\s+\1 matches a duplicated word like “the the.” Named groups (?<year>\d{4})make complex patterns readable. Non-capturing groups (?:...) let you use grouping for quantifiers without creating a numbered group you’ll never reference.

(d{4})-(d{2})-(d{2})   date with three groups
(?:foo|bar)+              non-capturing alternation
(?<y>d{4})-(?<m>d{2})   named groups
(w+)s+\1                repeated word

Flags

g finds all matches (not just the first). i is case-insensitive.m makes ^ and $ match line boundaries as well as string boundaries. s (dotall) makes . match newlines. uenables full Unicode matching in JavaScript. x (extended) lets you add whitespace and comments to the pattern for readability.

/hello/i      matches HELLO, Hello, hello
/^abc/gm      matches "abc" at start of each line
/a.b/s        the . matches newlines too

Lookahead and lookbehind

Lookaheads and lookbehinds are zero-width assertions—they check a condition without consuming characters. \d+(?=px) matches digits followed by “px” without including “px” in the match. (?<=\$)\d+ matches digits preceded by a dollar sign, without including the dollar sign. Negative versions(?!...) and (?<!...) assert absence.

The catastrophic backtracking trap

Some patterns, when faced with non-matching input, explore exponentially many paths. (a+)+b against aaaaaaaaaaaaaaaaX takes billions of steps before failing. The culprit is nested quantifiers matching the same thing. Warning signs: a group with a quantifier, where the group itself contains a quantifier that could match the same characters. Defensive rewrites include possessive quantifiers where available, atomic groups, or replacing .+ inside repeated groups with a restrictive character class like [^"]+.

Dangerous:  ^(w+)+$         nested quantifier
            ^(a|a)*$          ambiguous alternation
            ^(a|aa)*$         overlapping branches

Safer:      ^w+$             single quantifier
            ^[^"]*$           specific character class

Testing strategy

Keep a file with should-match and should-not-match lines for every regex you deploy. Run it every time you change the pattern. When a bug report comes in (“this string matched when it shouldn’t”), add the failing string to the test file first, verify the regex fails, then fix and re-run. This is unit testing for patterns.

Flavor differences

JavaScript, Python, PCRE (PHP, Perl), .NET, Go (RE2), and grep-style all have different capabilities. RE2 (Go, Rust’s regex crate) guarantees linear time but drops back-references and lookbehinds. JavaScript’s dotall flag is relatively recent. Test in the actual engine you’ll deploy against—a pattern that works on regex101 might behave differently in your language.

Common mistakes

Forgetting anchors. \d+ matches any digits anywhere. ^\d+$ requires the whole string to be digits. Choose deliberately; the wrong one causes false positives.

Using .* inside a larger pattern. The dot-star matches everything including too much, because it’s greedy. Use a specific character class like [^"]* for “anything but a quote” when parsing structured text.

Not escaping metacharacters. Dots in literal strings must be \.. Parentheses in literal phone numbers must be \( and \). example.com without escaping the dot matches “exampleXcom” too.

Using regex to parse HTML or JSON. HTML is not a regular language. Use a parser. Regex works for surgical extraction of simple patterns inside known structure, not for full parsing.

Ignoring Unicode. \w in JavaScript is ASCII-only by default, so café doesn’t match. Use the u flag plus\p{L} character classes for Unicode-aware matching.

Catastrophic backtracking in production. Nested quantifiers against adversarial input can freeze your service. Use linear-time engines (RE2, Rust regex) for anything that takes untrusted input, or add a timeout.

Not testing the negative cases. A regex that matches everything you want is useless if it also matches things you don’t. Always include should-not-match inputs in your test set.

Run the numbers

Paste your pattern and sample strings into our regex tester to see matches, captures, and flag behavior in real time. Pair it with the regex builder when you’re constructing a pattern from scratch, and the regex to English translator to verify you’re reading someone else’s pattern the way they intended.