Regex Tester
Live match highlighting, capture groups and a plain-English breakdown.
Regular expressions, tested where your code runs them
A regex behaves slightly differently in every engine. Testing a JavaScript
pattern in a PCRE-based tool and then shipping it is a reliable way to
discover the differences in production. This tester uses the browser's
native RegExp — the same engine your front-end code and your
Node services will use, so what you see here is what you get.
The flags, briefly
- g — find every match rather than stopping at the first. Almost always what you want when testing.
- i — case-insensitive.
- m — multiline:
^and$match at every line break instead of only at the ends of the string. - s — dotAll: lets
.match a newline, which it otherwise never does. The usual fix for a pattern that works on one line and fails across two. - u — full Unicode. Turn this on whenever the input might contain emoji or non-Latin scripts; without it,
.matches half a surrogate pair. - y — sticky: matches only from
lastIndex. Useful when hand-writing a tokeniser.
Named groups beat numbered ones
(?<year>\d{4}) is worth the extra characters. Numbered
groups renumber themselves the moment someone adds a parenthesis earlier in
the pattern, and the resulting bug is silent. Named groups are shown
alongside numbered ones in the results, and both work in the replacement
field.
Catastrophic backtracking
Nested quantifiers over overlapping character sets — the classic
(a+)+$ shape — make the engine explore an exponential number of
ways to divide the input. On a matching string it returns instantly; on a
near-miss it can run for longer than the universe has existed. When it
happens in a request handler that parses user input, it is a denial of
service with no packet flood required.
Matching here runs in a Web Worker with an 800ms wall-clock limit. That detail matters: a time check inside the matching loop cannot help, because the runaway happens inside a single operation and JavaScript is single-threaded — nothing else gets to run until it finishes. A worker can be terminated from outside, so the tab stays responsive and you get a warning instead of a hang.
If you see that warning, the pattern is not safe to run on untrusted input. The fix is to make the quantified parts unable to match the same characters, usually by replacing the inner quantifier with a more specific character class or by anchoring the pattern.
Nothing is sent anywhere
Regex test strings tend to be real data: log lines, customer records, the email addresses you are trying to extract. All matching happens in this tab.