Regex Tester and Explainer

Regex flavours are not interchangeable

This tester uses the JavaScript engine, because it runs in your browser. Most patterns behave identically across languages, but the differences catch people out when a pattern that works here fails in production.

The ones that matter: JavaScript has no \A or \z anchors — use ^ and $ with the m flag off. Lookbehind ((?<=...)) is supported in modern browsers but not in Safari before 16.4, and not in older Node. Unicode property escapes like \p{L} require the u flag. PCRE features such as atomic groups, possessive quantifiers and recursion do not exist in JavaScript at all.

Going the other way, Python's re module needs re.DOTALL where JavaScript uses the s flag, and Python names groups with (?P<name>...) rather than (?<name>...). If a pattern is destined for a different language, test it there before shipping.

Greedy, lazy, and the mistake everyone makes

By default, quantifiers are greedy: .* matches as much as it possibly can, then backtracks only as far as needed. This produces the single most common regex bug.

Given <b>bold</b> and <b>more</b>, the pattern <b>.*</b> matches the entire string, not the first tag — because .* swallows everything and then backs up to the last </b>. Adding ? makes it lazy: <b>.*?</b> stops at the first closing tag, which is almost always what was intended.

Better still, avoid . when you can name what you actually want. A negated character class like [^<]* is both clearer and faster, because it cannot match past the boundary in the first place and so never needs to backtrack.

That last point is not only about elegance. Patterns with nested quantifiers — the classic shape being (a+)+ — can take exponential time on input that nearly matches. This is catastrophic backtracking, and on a server processing user input it is a denial-of-service vulnerability. If a pattern hangs this tester, it will hang your application too.

Capture groups worth knowing

Parentheses do two jobs — grouping and capturing — and being deliberate about which you want makes patterns much easier to read.

• (...) captures, and the result is available as $1, $2 and so on in replacements.
• (?:...) groups without capturing. Use it whenever you only need the grouping, so your numbered groups stay meaningful.
• (?<name>...) captures by name, retrieved as $<name>. Far more maintainable than counting parentheses, and the right default for anything you will still be reading in six months.
• (?=...) and (?!...) are lookahead assertions: they test what follows without consuming it. Useful for rules like "a digit not followed by a percent sign".

A practical note on validation. Regular expressions are excellent for extracting structure from text and poor for validating it. Email addresses in particular are a trap — the fully correct pattern runs to thousands of characters, and every short version rejects valid addresses. Check for an @ with something on either side, then send a confirmation email. That is what actually establishes an address is real.

How to use the Regex Tester

1. Enter your pattern

   Write it without the surrounding slashes. Set flags separately below — g for all matches, i for case-insensitive, m for multi-line anchors.

2. Paste sample text

   Include cases that should match and cases that should not. A pattern that matches everything is as broken as one that matches nothing.

3. Read the explanation

   The explainer breaks the pattern into tokens and describes each one. When a pattern misbehaves, this usually shows why faster than staring at it.

4. Test a replacement

   Use the replace field with $1 or $<name> to reference captures, and check the preview before running it on real data.

Frequently asked questions