Regex Testing Tool

The Regex tool helps write, test, and understand regular expressions. A regular expression describes text patterns for search, extraction, validation, and replacement, such as email-like strings, log fields, URLs, IDs, dates, or repeated formatting. A tester makes matches, capture groups, flags, and edge cases visible before a pattern is used in code, a data pipeline, or form validation. Regex is powerful but easy to overtrust: a pattern may match too much or too little, become slow on large inputs, or handle Unicode and locale rules poorly. For complex parsers, HTML structures, or security-critical validation, a dedicated parser or library is often safer.

The tester is driven by the ECMAScript RegExp engine defined in the language spec. ECMAScript regex is a backtracking NFA implementation: the engine tries each alternative in left-to-right order and rewinds whenever a quantifier fails, which is what makes lookarounds and backreferences possible but also what produces catastrophic backtracking on adversarial inputs. The six flags it recognises are g (global), i (case-insensitive), m (multiline, anchors per line), s (dotAll, '.' matches newline), u (Unicode mode), and y (sticky, anchor to lastIndex). Matching semantics shift sharply between flags. Under /u, the engine treats the pattern as a sequence of Unicode code points instead of UTF-16 code units, so surrogate pairs match as one character and Unicode property classes like \p{L} (any letter), \p{Sc} (currency symbol), and \p{Script=Han} become available. Named capture groups (?<name>...) and lookbehind (?<=...) are part of ES2018 and ship in Chromium 64+, Firefox 78+, and Safari 16.4+, but PCRE-only features such as atomic groups (?>...) and possessive quantifiers (a++) are still not in the spec. The single largest production hazard is ReDoS — a pattern like (a+)+b on the input 'aaaaaaaaaaaaaaaa!' explores an exponential number of paths because two nested quantifiers can split the same character run in many ways. Mitigations are well known: avoid nested quantifiers over the same character class, anchor with ^ and $ where possible, prefer atomic groups when the engine supports them, or switch to a linear-time engine such as Go's RE2 (which trades backreferences and lookbehind for guaranteed O(n) matching). For untrusted input destined for server-side validation, RE2 or a hand-written parser is almost always the safer call.

• Engine: ECMAScript RegExp is a backtracking NFA, not a DFA; that is what enables lookarounds and backreferences but also enables catastrophic backtracking.
• Flags: g (global), i (case-insensitive), m (^/$ per line), s (dotAll, '.' matches \n), u (Unicode mode, surrogate-aware), y (sticky, anchored to lastIndex).
• Unicode mode: /u unlocks code-point matching plus \p{L} (letter), \p{Sc} (currency), \p{Script=Han}; without /u, [a-zA-Z]+ misses every non-Latin word.
• Modern syntax availability: named captures (?<n>...) and lookbehind (?<=...) ship in Chromium 64+, Firefox 78+, Safari 16.4+; atomic groups (?>...) and possessive quantifiers (a++) are not in ECMAScript.
• ReDoS: nested quantifiers over the same class such as (a+)+b explode exponentially; tighten with anchors, atomic groups, or migrate to RE2 / re2-wasm for untrusted input.
• Complexity floor: literal anchored patterns over a fixed alphabet run in O(n); backreferences and unbounded lookarounds push worst-case to exponential, so benchmark on adversarial input before shipping.