Regex Best Practices
Regular expressions are powerful and famously easy to write in a way that technically works on your test cases while hiding a performance or correctness problem that only shows up on different input later.
Last updated 2026-09-08
Avoid nested quantifiers that can cause catastrophic backtracking
A pattern like (a+)+ can, on certain non-matching input, cause the regex engine's backtracking to explode exponentially, hanging for seconds or minutes on a string that should fail instantly. Restructure nested repetition to avoid ambiguous matching paths.
Prefer specific character classes over overly broad ones like .*
A greedy .* matches as much as possible before backtracking to satisfy the rest of the pattern, which can produce wrong matches (matching too much) or performance problems on longer strings. A more specific character class matches exactly what's intended.
Anchor patterns explicitly when you mean to match the whole string
Without ^ and $ (or \A and \z), a pattern intended to validate an entire string can match successfully against just a substring within a longer, invalid string.
Don't try to validate everything with one enormous regex
An attempt to validate a fully RFC-compliant email address, for instance, in a single regex produces something enormous and nearly unmaintainable. A reasonably permissive pattern combined with actual verification (sending a confirmation email) is usually the better real-world architecture.
Test against deliberately tricky and adversarial input, not just the happy path
A regex that works on clean example input can still have a catastrophic-backtracking vulnerability that only appears on a long, almost-but-not-quite-matching string — test explicitly against that kind of input before shipping a pattern that processes untrusted data.
Common Mistakes to Avoid
- ⚠Nested quantifiers like (a+)+ or (a*)* that can cause catastrophic backtracking on certain input
- ⚠Unanchored patterns that were meant to validate an entire string but only match a substring
- ⚠Attempting a single, enormous regex to fully validate something (like RFC-compliant email) instead of a pragmatic pattern plus real verification
- ⚠Not testing a pattern against long or adversarial input before using it on untrusted user data
- ⚠Overusing .* where a more specific, bounded character class would be both faster and more correct
Frequently Asked Questions
What exactly is catastrophic backtracking?
It's when a regex engine, faced with certain nested-repetition patterns and specific non-matching input, tries an exponentially growing number of ways to make the match succeed before giving up — turning what should be an instant operation into one that can hang for a very long time.
Is it safe to run user-supplied regex patterns against user-supplied input?
Generally risky — a malicious or accidental catastrophic-backtracking pattern combined with the right input can hang a server (a ReDoS attack). If you must allow user-supplied patterns, run them with a strict timeout or in a sandboxed/rate-limited context.