Regex Tester

A regular expression (regex or regexp) is a compact pattern that describes a set of strings. Instead of searching for one fixed word, you describe the shape of what you want — "a four-digit year", "an email-like token", "a line that starts with ERROR" — and the regex engine finds every piece of text that fits. Patterns are built from literal characters plus metacharacters: character classes like \d (digit) and \w (word character), quantifiers like * (zero or more), + (one or more) and {2,4} (between two and four), anchors like ^ and $, groups in parentheses, and alternation with |. Regular expressions are used everywhere text is processed: search-and-replace in editors, input validation, log parsing, data extraction and scanning rules.

It uses your browser’s native JavaScript engine, so the flavor is ECMAScript (the same RegExp you get from new RegExp() or a /pattern/ literal in JS and Node.js). Most common syntax — character classes, quantifiers, anchors, groups, alternation, backreferences, lookahead and (in modern engines) lookbehind and named groups — behaves the same across flavors, but some features differ. ECMAScript has no inline modifiers like (?i), no possessive quantifiers or atomic groups, no \A/\Z anchors, and no recursion. Flags are set outside the pattern (the g, i, m, s, u, y toggles here). If you are targeting PCRE, Python’s re, Go’s RE2 or Java, verify any exotic construct against that engine — this tool reflects what the browser does.

They change how the pattern is applied. g (global) finds every match instead of stopping at the first — it is what lets this tester list all matches and replace all occurrences. i (ignore case) makes letters match regardless of case. m (multiline) makes the ^ and $ anchors match at the start and end of each line rather than only the whole string. s (dotAll) makes the dot . also match newline characters. u (unicode) treats the pattern as a sequence of Unicode code points and enables \u{...} escapes and \p{...} property classes. y (sticky) anchors each match attempt to the engine’s lastIndex, so matches must be contiguous from that position. Toggle them in the tester and the match list updates immediately.

Parentheses ( ) in a pattern create a capture group: the text matched inside them is remembered and numbered left to right ($1, $2, …), so you can pull sub-parts out of a match or reuse them in a replacement (e.g. turning 2026-01-15 into 15/01/2026 with $3/$2/$1). Named groups, written (?<year>\d{4}), capture to a name instead, referenced as $<year> in a replacement. A backreference like \1 inside the pattern matches the same text an earlier group captured. If you only want to group for precedence or alternation without capturing, use a non-capturing group (?:…). This tester shows every numbered and named group for each match, and marks a group that did not participate as "undefined".

Yes — the classic one is ReDoS (Regular-expression Denial of Service), caused by catastrophic backtracking. A pattern with nested or overlapping quantifiers, such as (a+)+$ or (.*a){20}, can take exponential time on certain inputs: a few dozen characters of the wrong shape can pin a CPU core for seconds, minutes or effectively forever. If that regex runs on attacker-controlled input in a request handler, one crafted string can stall or take down the service. Mitigations: prefer simple, anchored patterns; avoid nesting quantifiers over the same characters; set input-length limits; and consider a linear-time engine like RE2 for untrusted input. This tester defends itself by matching only a capped prefix of the test string, limiting how many matches it collects, and giving the global match loop a wall-clock time budget — but note that JavaScript runs a regex synchronously, so a single pathological match on a huge string can still be slow. Everything here stays in your browser, so testing a risky pattern never touches a server.