Regex Tester
Test regular expressions against sample text with live match highlighting.
| # | Match | Index | Groups |
|---|---|---|---|
| 1 | hello@example.com | 14 | — |
| 2 | support@gethubapps.com | 35 | — |
Test a regular expression against sample text with live match highlighting, so you can see exactly which parts of your text match, which capture groups fire, and iterate on a pattern without a slow write-run-debug cycle in actual code.
Supports standard regex flags (global, case-insensitive, multiline) so behaviour matches what you'd get running the same pattern in JavaScript.
Syntax quick reference
| Pattern | Matches |
|---|---|
| \d \w \s | A digit, a word character, whitespace |
| \D \W \S | The negation of each of the above |
| . | Any character except newline (unless the s flag is set) |
| * + ? | Zero or more, one or more, zero or one |
| {2,5} | Between 2 and 5 repetitions |
| *? +? | Lazy versions — match as little as possible |
| ^ $ | Start and end of string (or line, with the m flag) |
| \b | A word boundary |
| (abc) | A capture group |
| (?:abc) | A group that doesn't capture |
| (?<name>abc) | A named capture group |
| (?=abc) (?!abc) | Positive and negative lookahead |
| [a-z] [^a-z] | A character class and its negation |
| a|b | Alternation — a or b |
Why your pattern isn't matching
- Missing the global flag. Without g, only the first match is returned — the most common surprise.
- Greedy quantifiers. `<.*>` on `<a><b>` matches the whole string, not just `<a>`. Use `<.*?>` to match lazily.
- Unescaped metacharacters. A literal dot, question mark, bracket or slash must be escaped with a backslash.
- Dot doesn't match newlines by default. Add the s (dotAll) flag if your text spans lines.
- ^ and $ anchor to the whole string unless the m flag is set, in which case they anchor per line.
- Case sensitivity. Add i if the input casing isn't guaranteed.
Catastrophic backtracking
Nested quantifiers such as `(a+)+b` can take exponential time on input that nearly matches. On a string of 30 a's with no b, the engine tries millions of permutations before giving up — enough to hang a server, which makes this a denial-of-service vector known as ReDoS.
The fix is to avoid nesting a quantifier inside another quantified group, and to be specific rather than using `.*` where a narrower character class would do. If a pattern is slow here on a small sample, it will be catastrophic in production.
Frequently asked questions
- Which regex flavour does this use?
- It uses JavaScript's regular expression engine, so patterns and flags behave the same way they would inside a JS or TypeScript project.
- Why isn't my pattern matching what I expect?
- Common causes are a missing global flag when you expect multiple matches, greedy quantifiers matching more than intended, or unescaped special characters like `.` or `(` in the pattern.
- Does this show capture groups?
- Yes — matched capture groups are highlighted and listed separately alongside the full match, so you can verify a pattern extracts the right pieces.
- What's the difference between greedy and lazy matching?
- Greedy quantifiers (*, +) match as much as possible then backtrack; lazy ones (*?, +?) match as little as possible then expand. For extracting delimited content, lazy is usually what you want.
- Can I use regex to parse HTML?
- For anything beyond a trivially constrained snippet, no. HTML is not a regular language — nesting, attributes and comments defeat regex. Use a DOM parser instead.
- Why is my regex extremely slow?
- Most likely catastrophic backtracking from nested quantifiers like (a+)+. Restructure the pattern to avoid a quantifier inside a quantified group, and prefer specific character classes over .*