Regex Tester with ReDoS Detection

Regular expressions are pattern-matching mini-programs, and this tester does two jobs: it runs your pattern against sample text and reports every match with its position and capture groups, and it statically inspects the pattern itself for ReDoS (Regular expression Denial of Service) risk — without ever executing the dangerous case.

How matching works here. Enter a pattern, flags, and test text. Matches are listed with their index and captured groups, which is how you debug why a pattern is too greedy, misses an edge case, or captures the wrong span. The g flag is applied so you see all matches, not just the first. The other flags carry their usual JavaScript meaning: i for case-insensitive, m so ^ and $ match at line breaks, s so . also matches newlines, and u for full Unicode. Wrapping part of a pattern in parentheses creates a capture group whose text appears alongside each match — the fastest way to confirm you are extracting the right substring rather than just detecting a match.

Anchors and why they matter. A pattern without ^ and $ matches anywhere in the input, so \d{4} happily accepts abc1234xyz. For validation you almost always want to anchor the whole pattern so it must match the entire string end to end — an unanchored "validation" regex is a common source of bypass, letting an attacker prepend or append hostile characters around an otherwise-valid core.

What ReDoS is. Most regex engines (including JavaScript's) use backtracking. Certain pattern shapes make backtracking catastrophic: on input that almost matches, the engine explores exponentially many ways to split the string and effectively hangs. The classic culprits are nested quantifiers like (a+)+, ambiguous alternations under a quantifier like (a|a)*, and adjacent unbounded quantifiers like .*.*. A single crafted input against a vulnerable pattern can peg a CPU core and take down a service.

Why static detection. The tool inspects the pattern's structure — group nesting, quantifiers, alternation overlap — rather than feeding it a malicious string, so checking a risky pattern is itself safe and instant. It grades findings from informational up to critical nested-quantifier warnings.

Worked example. The infamous "validate an email with one clever regex" patterns often contain ([a-zA-Z0-9])+ groups that are themselves repeated — exactly the nested-quantifier shape that backtracks catastrophically. The tool flags these so you rewrite them before they reach production.

Defensive angle. Prefer simple, anchored patterns with bounded quantifiers ({1,64} instead of +); avoid nesting quantifiers; and where possible use a linear-time engine (RE2) or validate with plain string logic. If user input ever reaches a regex, either the pattern or the input length must be strictly bounded — an unbounded pattern over unbounded input is a denial-of-service waiting to happen.