Catastrophic backtracking occurs when a regular expression engine explores an exponentially growing number of possible matches due to nested or overlapping quantifiers. When a pattern fails to match, the engine backtracks and tries alternative paths—potentially millions or billions of them—causing the regex to hang or take an extremely long time. Classic examples include patterns like (a+)+b matched against aaaaaaaaaaaaaaac, where the engine exhaustively tries every possible grouping of "a"s before finally failing on the "c".

Common dangerous patterns include:

• Nested quantifiers: (a+)+, (a*)*, (.+)+
• Overlapping alternation: (a|aa)+ where one alternative is a prefix of another
• Multiple greedy quantifiers in sequence: .*.*=.* or .+.*
• Quantified groups with internal quantifiers: ([a-z]+)*
• Complex lookarounds with quantifiers: patterns that combine lookaheads/lookbehinds with repeating groups

Several strategies can prevent or fix catastrophic backtracking:

• Use possessive quantifiers (++, *+, ?+) where supported, which prevent backtracking into quantified subexpressions.
• Use atomic groups (?>...) to prevent the engine from revisiting matched content.
• Rewrite overlapping alternations to be mutually exclusive, e.g., change (a|aa)+ to a+.
• Avoid nested quantifiers by simplifying the pattern structure.
• Use lazy quantifiers (+?, *?) when greedy matching isn't required.
• Set reasonable timeouts in your regex engine (most modern engines support this).
• Pre-validate input length before applying complex patterns.

This tool runs your regex inside a Web Worker—a separate browser thread—so the main page remains responsive even if the regex hangs. If execution exceeds the timeout you set (default 3 seconds), the worker is terminated and you see a timeout warning. The tool also analyzes your pattern statically before execution, detecting known-dangerous structures like nested quantifiers and overlapping alternations. The benchmark feature tests the regex against progressively longer strings to reveal exponential time growth—a hallmark of catastrophic backtracking.

Possessive quantifiers (++, *+, ?+, {n,m}+) match as much as possible and never give back matched characters during backtracking. They are supported in Java, PHP PCRE, Perl, and Ruby, but not in JavaScript.

Atomic groups (?>...) work similarly—once the group matches, the engine won't revisit it to try alternative paths. Also not natively supported in JavaScript, though some libraries emulate them.

In JavaScript, the best alternatives are to simplify patterns, use lazy quantifiers where appropriate, and pre-validate input to avoid runaway matches.

This is the classic symptom of catastrophic backtracking. With a short input, the regex engine explores all backtracking paths quickly because the total number of combinations is manageable. As the input length grows, the number of possible backtracking paths can grow exponentially. For example, (a+)+b on "aaaaac" might take microseconds, but on "aaaaaaaaaaaaaaaac" it could take seconds or minutes. The benchmark feature in this tool helps you visualize this by testing multiple string lengths and showing how execution time scales.

Yes. JavaScript uses a backtracking regex engine (ECMAScript specification), which is susceptible to catastrophic backtracking. Unlike some other engines (like RE2 or Rust's regex crate), JavaScript's built-in RegExp does not guarantee linear-time matching. This means poorly crafted patterns can cause significant performance issues in Node.js servers, browser-based applications, and anywhere JavaScript runs. Always test your regex patterns with tools like this one before deploying them in production.