Regex Tester
Test a regular expression against sample text and see what it matches before committing it to code.
Syntax reference
| Pattern | Matches |
|---|---|
. | Any character except newline |
\d \w \s | Digit, word character, whitespace |
\D \W \S | The negation of each above |
^ $ | Start and end of string (or line, in multiline mode) |
\b | Word boundary |
* + ? | Zero or more, one or more, zero or one |
{n,m} | Between n and m repetitions |
*? +? | Lazy variants — match as few as possible |
(...) | Capturing group |
(?:...) | Non-capturing group |
(?=...) (?!...) | Positive and negative lookahead |
[abc] [^abc] | Character class and its negation |
Greedy versus lazy
Quantifiers are greedy by default: <.*> against <a><b> matches the entire string, not just <a>, because .* consumes as much as it can while still allowing the pattern to succeed. Adding ? makes a quantifier lazy, so <.*?> matches <a> alone. Most surprising regex behaviour traces back to this distinction.
Catastrophic backtracking
Nested quantifiers over overlapping character classes, such as (a+)+b, can force a backtracking engine to explore exponentially many paths before admitting failure. On attacker-supplied input this becomes a denial of service, known as ReDoS. Prefer possessive quantifiers or atomic groups where your engine supports them, and be wary of user-supplied patterns.