Regex Tester

The same pattern can behave differently in three engines

There is no single 'regex' — there's a family of engines that agree on the basics and diverge at the edges, and a pattern copied from a Stack Overflow answer written for one can quietly misbehave in another. This tester runs the browser's ECMAScript engine, which is exactly what your front-end and Node.js code will execute, so what you see here is what production does. The differences that bite are concrete: ECMAScript got lookbehind only in ES2018, so a pattern relying on it fails in older runtimes; PCRE (PHP, and the syntax most online testers historically used) supports recursion and conditionals that JavaScript has no equivalent for; and Go and Rust commonly use RE2, which deliberately drops backreferences and lookaround entirely in exchange for a guarantee the others don't make.

Practical consequence: test in the flavour you'll deploy in. A pattern that's elegant in PCRE can be impossible to express in RE2, and one that works in RE2 is always safe in PCRE but not vice-versa.

Why RE2 throws features away — and why that's the safe default for untrusted input

The traditional backtracking engines (PCRE, ECMAScript, .NET, Java) are powerful because they can backtrack — try a path, fail, rewind, try another. That power is also the trap: certain patterns make the engine explore exponentially many paths, so a pattern that runs instantly on a short string can hang for seconds, or effectively forever, on a slightly longer one. This is catastrophic backtracking, and when an attacker can supply either the pattern or the input, it becomes a denial-of-service vector — see OWASP's ReDoS write-up.

RE2 sidesteps the whole class by using a finite-automaton approach with linear-time guarantees, which is precisely why it forbids backreferences and lookaround — those features require backtracking. If you're matching regexes against user-supplied data on a server, an RE2-family engine is the defensive choice; if you're matching trusted patterns against trusted input in the browser, the convenience of lookaround is usually worth it.

The patterns that blow up, and how to spot them

• Nested quantifiers over overlapping classes — (a+)+$, (\d+)*$, and friends. Against a long non-matching string these are the textbook exponential case; flatten them to a single quantifier.
• Alternation where branches can match the same text — (a|a)* or (\w|\s)* forces the engine to try every combination. Make branches mutually exclusive.
• Unanchored patterns scanned across a huge input — anchor with ^ and $ or \b where the match must start, so the engine fails fast instead of retrying at every position.
• Greedy .* followed by a specific tail in a long line — the engine grabs everything then backtracks character by character. A negated class like [^"]* is often dramatically faster than .*.

Everyday mistakes that aren't backtracking

• Forgetting the g flag and wondering why replace only touches the first match, or why a match loop never advances.
• Using . to mean 'any character' and being surprised it skips newlines — that needs the s (dotAll) flag; m only changes what ^ and $ anchor to.
• Not escaping a literal dot, slash, or brace, so example.com matches exampleXcom too.
• Reaching for a regex to parse HTML or JSON structurally — use a real parser like the JSON tool; regex can't balance nested delimiters and will silently mismatch on the first edge case.