How do I check what my capture groups actually captured?

Run your pattern against a real sample and look at the per-match groups table: it lists each capture group's value by number, plus any named groups (written as (? ...)) by name. This is the fastest way to confirm group 1 is really the part you think it is, especially in patterns with several nested or optional groups.

How can I preview a find-and-replace before running it in my code?

Use a replace preview: enter your pattern, turn on the 'g' flag if you want every match replaced, and type a replacement string that can reference capture groups with $1, $2… (or $ for named groups). The tool shows the resulting text instantly, so you catch formatting mistakes — like a stray $1 typo — before the change ever touches real code or data.

What is ReDoS and how do I know if my pattern is at risk?

ReDoS (Regular expression Denial of Service) happens when nested or overlapping quantifiers, like (a+)+, cause the matching engine to try an exponential number of combinations on certain inputs, freezing the page or server. A ReDoS quick-check badge runs your pattern against a few adversarial repeated-character strings in your browser and flags it if any probe takes noticeably longer than expected. It's a best-effort heuristic, not a formal proof, but a flagged pattern is worth rewriting with more specific character classes or non-capturing groups.

Why Doesn't My Regex Match? A Practical Debugging Guide

Q: Why does my regex match nothing at all?

The most common causes are a missing 'g' flag when you expect multiple matches, forgetting to escape a literal dot or parenthesis, or using ^ and $ anchors while the 'm' flag is off (so they only match the very start/end of the whole string, not each line). Paste your pattern and text into a live tester with match highlighting — if nothing lights up, try removing anchors or flags one at a time to isolate which part is blocking the match.

Q: Why does my regex match too much (it's too greedy)?

Quantifiers like * and + are greedy by default — they grab the longest possible match. For example, against ' bold ' matches the entire string instead of just ' '. Adding a ? after the quantifier (*? or +?) makes it lazy, matching the shortest possible string instead. Watch the live highlight update as you toggle between greedy and lazy to see exactly where the match boundary moves.

Your pattern looks right, the string looks right, and still — nothing matches, or it matches way more than you expected. Here's how to actually find out why, using live highlighting instead of guessing.

Why does my regex match nothing at all?

Short answerUsually one of three things: a missing g flag when you expected repeated matches, an unescaped special character, or anchors (^/$) combined with an "off" m flag when your text has multiple lines.

Regex debugging is hard mostly because failures are silent — a pattern that matches nothing doesn't throw an error, it just quietly returns zero results. The fastest way to isolate the problem is to paste both the pattern and a small, realistic sample string into a tester that highlights matches as you type, then remove pieces of the pattern one at a time until something lights up.

A common trap: forgetting that ., (, ), +, and ? are special characters. If you want a literal period (as in a filename or an IP-style string), it needs to be escaped as \. — otherwise it silently matches "any character," which can look like it's working until an edge case breaks it.

Key fact: ^ and $ anchor to the start/end of the whole string by default. Checking the m (multiline) flag makes them anchor to the start/end of every line instead — a frequent source of "it matches line 1 but not line 3" confusion.

Why does my regex match too much (it's too greedy)?

Short answerQuantifiers (*, +, {n,m}) are greedy by default, grabbing the longest possible match. Add a ? right after the quantifier to make it lazy instead, so it grabs the shortest possible match.

Take the pattern <.*> against the text <b>bold</b>. A greedy quantifier stretches from the very first < all the way to the very last >, swallowing the whole string instead of just the opening tag. Changing it to <.*?> makes the quantifier lazy, so it stops at the very next > it finds.

Here's an example of how the same input behaves differently depending on greediness — this is illustrative, not a fixed rule for every pattern:

Example only — greedy vs. lazy on "<b>bold</b>"
Pattern	Behavior	Match on this example
<.*>	Greedy	<b>bold</b>
<.*?>	Lazy	<b>

Watching the live highlight change as you toggle a single ? is usually faster than reasoning through it in your head, especially with nested tags or repeated delimiters.

How do I read capture groups correctly?

Short answerCheck the per-match groups list: numbered groups like (\d{2})-(\d{2}) appear in order, and named groups written as (?<name>...) appear by name — both listed alongside the match position for each hit.

It's easy to miscount groups once a pattern has several optional or nested parentheses. A non-capturing group, written (?:...), groups characters together without being numbered — so if your pattern mixes capturing and non-capturing groups, the numbering can shift in ways that aren't obvious just from reading the pattern. Confirming against a real sample string, and checking exactly which value landed in group 1 versus group 2, avoids off-by-one mistakes before they reach production code.

How do I preview find & replace safely?

Short answerType your replacement string with $1, $2… (or $<name> for named groups) and preview the full output before running the substitution anywhere that matters.

For example (illustrative only), running the pattern (\d{4})-(\d{2})-(\d{2}) with replacement $2/$3/$1 against the sample string "2026-07-19" produces "07/19/2026." Previewing this kind of transformation against a handful of representative lines first catches a mistyped group reference — like $2 where you meant $3 — long before it silently corrupts real data.

If your replacement should apply to every match rather than just the first one, make sure the g flag is turned on; without it, only the first occurrence in the string is replaced.

What about catastrophic slowdowns (ReDoS)?

A less common but nastier failure mode is a pattern that works fine on short test strings but appears to hang on longer or more repetitive input. This is typically caused by ambiguous nested quantifiers — patterns like (a+)+ — where the matching engine can try an exponential number of ways to fail. A quick ReDoS check runs a pattern against a few adversarial repeated-character strings and flags anything that takes noticeably longer than expected, which is a useful early warning before that pattern ever reaches a server that processes untrusted input.