Regex Tester

Why regular expressions can be slow

Most implementations, including JavaScript’s, use a backtracking engine. It tries one way of matching, and if that fails it returns to the last choice point and tries the next. For ordinary patterns this is fast and supports features that a theoretically better algorithm cannot, such as backreferences. The failure mode appears when a pattern offers many overlapping ways to match the same text. Consider (a+)+ against a string of a characters followed by something that prevents a match: the inner repetition can take one character or two or five, and the outer repetition can then take the remainder in as many ways again. The engine must try every combination before concluding failure, and the number of combinations doubles with each additional character. This is not a bug in the engine — it is a consequence of the algorithm, and it has taken down production systems at several large companies, always in the same shape.

Why the work happens in a worker

The practical problem with catastrophic backtracking in a browser is that it cannot be stopped. There is no timeout parameter, no cancellation, no way for other code to run while the engine grinds. A long-running regex on the main thread blocks rendering, input handling and every timer; the tab appears to have crashed, because for all practical purposes it has. Running the match on a worker thread changes the situation entirely. The worker is a separate thread with its own event loop, so the page stays responsive no matter what the pattern does, and the worker can be terminated outright — which is the only reliable way to reclaim a thread stuck inside a regex. That is why this tool has a worker at all: not for speed, but so that the failure is recoverable.

Writing patterns that do not blow up

A few habits avoid almost all of the trouble. Make repetitions non-overlapping so the engine has no ambiguity to explore: prefer [^"]* to .* when matching inside quotes, because the negated class cannot match the terminator and so cannot backtrack past it. Anchor patterns when you know where they start, which lets the engine fail fast instead of retrying at every position. Avoid nesting quantifiers; where the structure genuinely needs it, an atomic group would help, but JavaScript has none, so restructure instead. And test against input that nearly matches but ultimately fails — that is the case that triggers the worst behaviour, and it is the one people forget to try, because a pattern that works on valid input feels finished.