How to Fix Regex "Catastrophic Backtracking" Performance Issues

Catastrophic backtracking is what happens when a regular expression, faced with input that almost — but not quite — matches, ends up exploring an exponential number of possible ways to match before finally giving up. The regex itself hasn't changed, but the time it takes to run can jump from milliseconds to literally minutes or hours on certain inputs, sometimes freezing the entire process, since JavaScript's regex engine runs synchronously on the main thread.

The classic pattern that causes this is nested quantifiers — something like (a+)+ or (a*)*. Each of those inner and outer quantifiers can match the same characters in many different combinations, and when the overall pattern ultimately fails to match, the engine backtracks through an exponential number of those combinations before concluding there's no match at all.

A very common real-world version of this shows up in email or URL validation regexes copied from Stack Overflow without fully understanding them — patterns like ([a-zA-Z0-9]+)+@ look reasonable at a glance, but the nested + quantifiers create exactly the exponential blowup described above, and a long string of characters with no @ sign at the end can hang the regex engine for a very long time trying every possible way to almost match.

The way to actually confirm this is your problem, rather than something else entirely, is to test the suspect regex against a deliberately crafted worst-case input — a long run of a repeated character with no valid match at the end, like 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!' for a pattern like (a+)+b. If that hangs while shorter versions of the same string return instantly, you've confirmed catastrophic backtracking rather than some other performance issue.

The real fix is almost always to rewrite the pattern to remove the ambiguity that causes exponential backtracking in the first place — usually by making inner quantifiers more specific (bounding them with exact character classes that don't overlap with the outer quantifier) or restructuring nested groups so there's only ever one way to match a given piece of input, not many equivalent ways.

For validation use cases specifically, it's also worth asking whether a full validation regex is even necessary — for something like an email address, a much simpler regex that just checks for a reasonable shape (something@something.something) combined with actually sending a verification email is both safer against backtracking and more honest about what regex validation can actually guarantee.

While you're rewriting a suspicious pattern, our Regex Tester lets you test it live against sample input and see exactly which parts match, which is a much faster feedback loop than editing code, saving, and re-running your application every time you tweak the pattern.