Regex Tester

Q: What is catastrophic backtracking, and why does this tool time out?

When a pattern contains nested quantifiers — (a+)+ is the classic — the engine can split the input between the inner and outer parts in exponentially many ways. If the match ultimately fails, it tries all of them. Twenty characters might take a millisecond, thirty a second, forty several minutes. Because JavaScript's regex engine cannot be interrupted mid-match, this tool runs your pattern in a background worker and kills it after 0.8 seconds. Being stopped is the finding: the same pattern on a server means one crafted request can consume a CPU core indefinitely.

Q: Why does my regex match nothing?

In rough order of frequency: case sensitivity — add `i`; anchors, since `^` and `$` match the whole string unless `m` is on; over-escaping, as inside a JavaScript string literal `\d` must be written `\\d` but here you type it directly; and character classes, where `-` means a range unless it is first or last. Paste the pattern exactly as the engine sees it, not as it appears in your source code.

Q: What is the difference between greedy and lazy quantifiers?

Greedy quantifiers (`*`, `+`, `{n,}`) take as much as they possibly can, then give characters back until the rest of the pattern fits. Lazy ones (`*?`, `+?`) take as little as possible and add more only when forced. It matters most with `.`: given ` bold `, the pattern ` ` matches the entire string because the greedy `.*` runs to the last `>`, while ` ` matches just ` `.

Q: Do capture groups slow a pattern down?

Slightly, because each one allocates a slot the engine has to fill and track. If a group exists only to apply a quantifier to several characters, write it as a non-capturing group `(?:...)` instead. The difference rarely matters at the scale of a form validation, but it is real inside a loop over a large file — and non-capturing groups also keep your numbered references stable when you add grouping later.

Q: Does this work for Python, PHP or Java regex?

Mostly, for the common constructs — character classes, quantifiers, anchors, groups and alternation are shared across all of them. The differences appear at the edges: lookbehind support, named group syntax, Unicode property escapes and possessive quantifiers all vary. Go's RE2 is the biggest departure, because it uses a non-backtracking engine that guarantees linear time but drops backreferences and lookaround entirely. Test anything unusual in the language you will actually ship it in.

Q: How do I use capture groups in a replacement?

Numbered groups are `$1`, `$2` and so on, in the order their opening parentheses appear. Named groups use `$ `. `$&` inserts the whole match, and `$$` inserts a literal dollar sign. The replace field here previews exactly what JavaScript's String.replace would produce, so what you see is what your code will do.

Test a regular expression live, see every capture group, and catch patterns that backtrack catastrophically.

Pattern

/ /

g global i ignore case m multiline s dotAll u unicode y sticky

Test string

Replace with — optional; $1, $2 and $<name> work

Result

Matches and capture groups

#	Match	Groups

What It Does

This tool matches your pattern against a test string as you type, highlights every match in place, and lists what each capture group caught. It also does something most testers do not: it runs the match in a background worker with a time limit, so a pattern that backtracks catastrophically gets caught and reported instead of freezing the page. That failure mode is a real denial-of-service risk in production, and this is the cheapest place to discover it.

When to Use It

You are writing a validation pattern and need to see it match and fail against real examples.
A regex works on your machine and not in production, and you need to compare behaviour flag by flag.
You are doing a bulk find-and-replace and want to preview the result before running it.
You inherited a pattern and need to work out what it captures and in what order.

Worked Examples

Extract email addresses

The everyday case. Note this is deliberately a pragmatic pattern rather than a fully RFC-compliant one — the truly correct email regex is thousands of characters long and matches addresses no mail server will accept.

Named capture groups

Named groups make the matching code readable, and the replace field shows how $<name> reorders them. Far clearer than remembering that $1 is the year.

Greedy versus lazy

One match spanning the whole line, because .* is greedy and takes as much as it can. Change it to <.*?> and it matches each tag separately — the single most common regex surprise.

Catastrophic backtracking (ReDoS)

This will be stopped after 0.8 seconds. The nested quantifiers make the engine try exponentially many ways to split the a's, and adding a few more characters turns milliseconds into hours. On a server, one crafted request like this pins a CPU core.

Common Mistakes

Forgetting the global flag. Without `g`, only the first match is ever returned, which makes a pattern look broken when it is actually working exactly as asked. This tool reports when `g` is off and matches exist.
Using a greedy quantifier where a lazy one is meant. `.*` takes as much as possible before backing off, so `<.*>` swallows an entire line of HTML rather than one tag. The lazy `.*?` is almost always what you wanted.
Writing nested quantifiers such as (a+)+ or (\d+)*. These make the engine explore exponentially many ways to match, so a slightly longer input takes astronomically longer. It is a genuine denial-of-service vector, and it is why this tool runs your pattern on a timer.
Assuming \d and \w cover more than ASCII. Without the `u` flag they match only ASCII digits and word characters, so names with accents, non-Latin scripts and emoji all behave unexpectedly.
Parsing HTML with a regular expression. HTML is nested and regular expressions are not; any pattern that appears to work will fail on comments, attributes containing angle brackets, or unclosed tags. Use a parser.
Testing only the strings that should match. A validation pattern is defined as much by what it rejects, and an anchorless pattern happily matches inside a longer string — which is how `\d{5}` accepts a 20-digit input.

Features

Live match highlighting as you type

Capture groups and named groups listed per match

Replace preview with $1 and $<name> support

All six JavaScript flags with inline explanations

Catastrophic backtracking detection with a hard timeout

Runs in a background worker so the page never freezes

Empty-match and missing-flag warnings

Greedy quantifier and Unicode hints

Runs entirely in your browser

How to Use

1. Type your pattern between the slashes — no need to escape forward slashes. 2. Tick the flags you need; `g` is on by default. 3. Paste your test string; matches highlight as you type. 4. Read the capture group table to see what each group caught. 5. Optionally enter a replacement to preview the result. 6. If the pattern is stopped for taking too long, treat that as a finding rather than a tool failure.

Frequently Asked Questions

What is catastrophic backtracking, and why does this tool time out?

Why does my regex match nothing?

What is the difference between greedy and lazy quantifiers?

Do capture groups slow a pattern down?

Does this work for Python, PHP or Java regex?

How do I use capture groups in a replacement?

Embed this Regex Tester

Paste this snippet into your site to embed the tool.

<iframe src="https://webtoolworld.com/embed/regex-tester" style="width:100%;min-height:560px;border:0" loading="lazy" title="Regex Tester"></iframe>
<p style="font-size:12px;margin-top:6px"><a href="https://webtoolworld.com/regex-tester">Regex Tester</a> by WebToolWorld</p>

This tests JavaScript regular expressions, using your browser's own engine. Other flavours differ in real ways — PCRE, Python, Go's RE2 and Java each support constructs JavaScript does not, and RE2 in particular cannot backtrack at all, which makes it immune to the ReDoS problem described here. A pattern that works here may need adjusting elsewhere. Everything runs in your browser; your pattern and test string are never uploaded. The backtracking detection uses a time limit, so a pattern that is merely slow on a very large input may occasionally be reported alongside genuinely exponential ones.