Regex Tester & Explainer

Why this one cannot hang your browser

A JavaScript regular expression cannot be interrupted. Once the engine starts backtracking there is no timeout and no way to abort, which is why so many online regex testers freeze the tab on a pattern like (a+)+$ tested against a long run of the same character. That pattern asks the engine to try an exponential number of ways to split the input, and on thirty characters it is already about a billion attempts.

So the match runs in a Web Worker - a second thread - with a one-second watchdog on the main thread. If the worker has not answered by then it is terminated outright, which is the only mechanism in the platform that can stop a runaway regex, and the result is reported as a finding rather than an error. That finding is worth having: the same pattern would pin a CPU in production, which is the ReDoS class of vulnerability, and most testers will simply die rather than tell you.

What you get back

Every match with its index, line and column, and each capture group listed by number or by name - including groups that did not participate, which are shown as such rather than omitted, because a group matching nothing and a group matching an empty string are different situations and confusing them is a real bug.

Replacement mode uses the browser's own substitution syntax, so $1, $<name>, $& and $$ behave exactly as they will in your code rather than in a re-implemented dialect. Split mode shows every part including the empty ones.

• Flags i, m, s and u as switches, with what each one changes
• Named capture groups via the (?<name>...) syntax
• Match, replace and split modes over the same pattern
• A hint when a failed match would have succeeded with the i or m flag

The pattern, read out loud

The explanation panel walks the pattern token by token: what each character class matches, which groups capture and which do not, what a quantifier repeats and whether it is lazy, and what a lookahead asserts without consuming. It is a flat left-to-right reading rather than a nested one, because a partial parser's failure mode is a confidently wrong explanation.

What it will not do

This is the JavaScript flavour. PCRE, Python, Go's RE2 and .NET differ in ways that matter - recursion, atomic groups, possessive quantifiers and variable-length lookbehind are absent here - so a pattern verified on this page is verified for JavaScript, and Go's RE2 in particular deliberately has no backtracking at all, which is why it cannot suffer the problem described above.

It also will not write a regular expression for you, and it will not tell you that a pattern is correct - only what it matches against the text you supplied. A pattern that passes on three examples and fails on the fourth is the normal outcome of testing with too few examples.