Regex Tester

Catastrophic backtracking and why a worker is used

The JavaScript regular expression engine is a backtracking engine: when a path fails it rewinds and tries the alternatives. Nested quantifiers make the number of those alternatives grow exponentially with input length. The pattern /^(a+)+$/ is the textbook case. Give it a subject made entirely of a characters with one trailing character that defeats the match, and the engine has to try every possible way of splitting those a characters into groups.

1const pattern = /^(a+)+$/;2 3pattern.test('aaaaaaaaaa!');   // 10 a's: instant4pattern.test('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'); // 30 a's: minutes5 6// Why: (a+)+ tries 2^(n-1) ways of splitting n a's into groups.7// Because the final character never matches, the engine must exhaust ALL of them.8 9// Fix 1: remove the nested quantifier10/^a+$/.test('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'); // instantly false11 12// Fix 2: remove the ambiguity13/^(?:[^a]|a)+$/ // non-overlapping alternatives leave nothing to backtrack into

This is the attack surface known as ReDoS. If you match user-supplied text against such a pattern on a server, an attacker can occupy a process for minutes with a single request. In a browser the effect is more visible: the tab freezes, because matching runs synchronously on the main thread and nothing can interrupt it.

The lastIndex state and alternating results

In JavaScript a regular expression is a stateful object, not an immutable value. With the g or y flag it carries a writable lastIndex field, and both test and exec advance it after every successful match. Reuse the same object across calls and results alternate between true and false. This is one of the most common regular expression bugs in production code.

1const re = /ada/g;2 3re.test('ada'); // true   (lastIndex is now 3)4re.test('ada'); // false  (search started at index 3, lastIndex resets to 0)5re.test('ada'); // true   (the cycle begins again)6 7// A module-level pattern is dangerous for exactly this reason:8const EMAIL = /\S+@\S+/g;9function isValid(value) {10  return EMAIL.test(value); // false on every second call with the same input11}12 13// Three correct approaches:14const EMAIL_STATELESS = /\S+@\S+/;      // 1. drop the g flag15EMAIL.lastIndex = 0;                      // 2. reset before each use16[...value.matchAll(/\S+@\S+/g)];         // 3. use matchAll (it works on a clone)

Zero-length matches and infinite loops

When a pattern can match the empty string (a*, \b, (?:) and friends), an exec loop does not advance on its own. A zero-length match leaves lastIndex where it was, so the loop reads the same position forever. This is precisely why the matcher behind this tool uses a hand-written exec loop rather than matchAll: it bumps lastIndex manually whenever it sees a zero-length match.

1const re = /a*/g;2let m;3 4// INFINITE LOOP: an empty match at every position in 'bbb', no progress5while ((m = re.exec('bbb')) !== null) {6  console.log(m.index, JSON.stringify(m[0])); // 0 "" ... 0 "" ... 0 ""7}8 9// CORRECT: advance the cursor yourself on a zero-length match10while ((m = re.exec('bbb')) !== null) {11  console.log(m.index, JSON.stringify(m[0]));12  if (m[0].length === 0) {13    re.lastIndex++;14    if (re.lastIndex > 'bbb'.length) break;15  }16}

Non-ASCII letters and the Turkish i

The \w shorthand is defined over ASCII and means exactly [A-Za-z0-9_]. None of ş, ğ, ı, ü, ö or ç match it. A \w+ pattern trying to capture words in Turkish text splits "çiçek" into "i" and "ek". The same limitation applies to the \b word boundary, since it is defined in terms of \w.

1'çiçek bahçesi'.match(/\w+/g);2// ['i', 'ek', 'bah', 'esi']   <-- the Turkish letters counted as boundaries3 4// Fix 1: spell the character class out5'çiçek bahçesi'.match(/[a-zçğıöşü]+/gi);6// ['çiçek', 'bahçesi']7 8// Fix 2: the u flag with a Unicode property escape (cleanest)9'çiçek bahçesi'.match(/\p{Letter}+/gu);10// ['çiçek', 'bahçesi']

The subtler problem is case folding. Turkish treats the dotted and dotless i as separate letters: the uppercase of i is İ, and the uppercase of ı is I. The regular expression engine, however, uses the default Unicode case-folding table, in which the uppercase of i is I. As a result the i flag produces wrong matches for Turkish text, and because the bug only appears in words containing an i it slips through test suites easily.

In application code the most reliable approach is normalising both sides with toLocaleLowerCase("tr") before comparing. In user-facing places such as a search box, that single line removes every surprise the i flag can produce. The same class of problem exists in other locales too, so if you localise, treat case-insensitive matching as a locale-dependent operation rather than a free one.

Named groups and the d flag

Naming capture groups instead of indexing them removes the match[3] style access that breaks the moment you edit the pattern. The d flag adds an indices array giving the start and end offsets of every group, which is what you need for highlighting or partial replacement. This tool shows named groups as their own column in the results table.

1const pattern = /(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/d;2const m = pattern.exec('due: 2026-07-26');3 4m.groups.year;         // '2026'5m.groups.month;        // '07'6m.indices.groups.day;  // [13, 15]  <-- undefined without the d flag7 8// Replacement can address groups by name too:9'2026-07-26'.replace(pattern, '$<day>/$<month>/$<year>');10// '26/07/2026'