Validating user input (email-shaped, phone-shaped, postcode-shaped) and seeing exactly which inputs pass and fail. Parsing log lines, extracting fields, building log filters. Designing find-and-replace patterns before running them across a real codebase. Debugging a regex you copied from Stack Overflow that doesn't work — paste it here, see what it actually matches.

\b\w+@\w+\.\w+\b — email-ish ^\s*$ — empty/whitespace-only line (with m flag) (? \d{4})-(? \d{2}) — named capture groups (?:.*) — non-capturing group (?=foo) / (?!foo) — lookahead / negative lookahead

JavaScript ≠ PCRE. No \K , no recursive patterns, lookbehind only since ES2018. Patterns from Perl, PHP, or Python often need adjustment. Without g flag you get the first match only. Add g for "find all"; combine with m if anchors should match per-line. Greedy vs lazy. .* grabs as much as possible; .*? grabs as little. The difference between matching hi and there as one block vs two. Anchors at line vs string boundaries. ^ and $ match string ends by default; with m flag they match each line. Replacement specials. $& is the whole match; $1 , $2 , … are capture groups; $$ is a literal $ . Forgetting that is a common source of "why is my regex eating my dollars". Don't parse HTML with regex for anything serious. The classic warning is true: nested tags, comments, and CDATA need a real parser. Regex is fine for one-off log scraping or controlled inputs.

Regex flavours are not interchangeable. JavaScript's regex engine (which this tool uses) is close to PCRE but not identical. Notable JS-specific differences: no recursive patterns, no \K reset operator, no atomic groups before ES2018, and look-behind (?<=…) only landed in 2018. A pattern that "works in PHP" may not transfer to JS without rewriting. Test in the actual target engine before relying on it. Catastrophic backtracking is the silent regex killer. Patterns like (a+)+b can take exponential time on inputs that don't match — the engine tries every combination of how the inner a+ could subdivide the input. On modern engines (V8 since 2020) most cases short-circuit, but older engines and certain pathological patterns still hang the page. If a regex test takes more than a fraction of a second on short input, you have a problem. Unicode awareness is opt-in. By default, \w in JavaScript regex matches only ASCII [A-Za-z0-9_] — not "é", not "中", not "العربية". To get Unicode-aware matching, add the u flag, and for full Unicode property classes (matching every letter regardless of script), use \p{L} with the u flag. Email validators and "word" matchers written without these silently fail on non-ASCII text. Greedy vs lazy is about backtracking direction. .* greedy consumes everything then backs off; .*? lazy consumes nothing then expands. Same final match on simple inputs; very different performance on complex ones. Default to lazy when you have an explicit terminator ( .*? is almost always what you want, not .* ). For production validators, write tests, not regex. Common regex mistakes — over-permissive email validators that accept foo@bar , IP-address patterns that match 999.999.999.999 , URL patterns that miss IDN domains — are best caught by a unit-test suite with real-world positive and negative examples. The regex itself is the implementation; the tests are the spec.

Regex Tester

Test JavaScript regular expressions live. See matches, capture groups, and apply replacements as you type.

Pattern

/ /

Flags: g global · i case-insensitive · m multi-line · s dotAll · u unicode · y sticky

Test string

Highlighted matches

Capture groups

Enter input above to see the result.

Replace

Use $1, $2 for groups · $& for the whole match · $$ for literal $

Enter input above to see the result.

What is this for?

Regular expressions are dense and unforgiving. The way to write one that actually works is iteratively — pattern, sample text, see what matches, adjust. This tool gives you that loop in your browser using the JavaScript engine's native RegExp, plus capture-group inspection and a replacement preview. Patterns and inputs never leave the page.

When to use it

Validating user input (email-shaped, phone-shaped, postcode-shaped) and seeing exactly which inputs pass and fail.
Parsing log lines, extracting fields, building log filters.
Designing find-and-replace patterns before running them across a real codebase.
Debugging a regex you copied from Stack Overflow that doesn't work — paste it here, see what it actually matches.

Common patterns

\b\w+@\w+\.\w+\b — email-ish
^\s*$ — empty/whitespace-only line (with m flag)
(?<year>\d{4})-(?<month>\d{2}) — named capture groups
(?:.*) — non-capturing group
(?=foo) / (?!foo) — lookahead / negative lookahead

Common gotchas

JavaScript ≠ PCRE. No \K, no recursive patterns, lookbehind only since ES2018. Patterns from Perl, PHP, or Python often need adjustment.
Without g flag you get the first match only. Add g for "find all"; combine with m if anchors should match per-line.
Greedy vs lazy. .* grabs as much as possible; .*? grabs as little. The difference between matching <b>hi</b> and <i>there</i> as one block vs two.
Anchors at line vs string boundaries. ^ and $ match string ends by default; with m flag they match each line.
Replacement specials. $& is the whole match; $1, $2, … are capture groups; $$ is a literal $. Forgetting that is a common source of "why is my regex eating my dollars".
Don't parse HTML with regex for anything serious. The classic warning is true: nested tags, comments, and CDATA need a real parser. Regex is fine for one-off log scraping or controlled inputs.

Expert notes

Regex flavours are not interchangeable. JavaScript's regex engine (which this tool uses) is close to PCRE but not identical. Notable JS-specific differences: no recursive patterns, no \K reset operator, no atomic groups before ES2018, and look-behind (?<=…) only landed in 2018. A pattern that "works in PHP" may not transfer to JS without rewriting. Test in the actual target engine before relying on it.
Catastrophic backtracking is the silent regex killer. Patterns like (a+)+b can take exponential time on inputs that don't match — the engine tries every combination of how the inner a+ could subdivide the input. On modern engines (V8 since 2020) most cases short-circuit, but older engines and certain pathological patterns still hang the page. If a regex test takes more than a fraction of a second on short input, you have a problem.
Unicode awareness is opt-in. By default, \w in JavaScript regex matches only ASCII [A-Za-z0-9_] — not "é", not "中", not "العربية". To get Unicode-aware matching, add the u flag, and for full Unicode property classes (matching every letter regardless of script), use \p{L} with the u flag. Email validators and "word" matchers written without these silently fail on non-ASCII text.
Greedy vs lazy is about backtracking direction. .* greedy consumes everything then backs off; .*? lazy consumes nothing then expands. Same final match on simple inputs; very different performance on complex ones. Default to lazy when you have an explicit terminator (.*?</div> is almost always what you want, not .*</div>).
For production validators, write tests, not regex. Common regex mistakes — over-permissive email validators that accept foo@bar, IP-address patterns that match 999.999.999.999, URL patterns that miss IDN domains — are best caught by a unit-test suite with real-world positive and negative examples. The regex itself is the implementation; the tests are the spec.