Regex Tester & Debugger

How it works

The tester builds a regular expression from the pattern and flags you type, using the same new RegExp(pattern, flags) constructor that your own code would call. It then runs that object against the text in the test area. Without the g flag the engine evaluates the first match, and the page reports its index and its capture groups. With g enabled the page walks every match through String.prototype.matchAll, which returns an iterator of match results, so each result carries its own position, its numbered groups, and any named groups defined in the pattern. The matched spans are then spliced back into the text stream to produce the highlights you see.

Nothing is sent to a server. Matching runs inside the page, in your browser's own JavaScript engine.

JavaScript regular expressions are interpreted by a backtracking engine. When a quantified group such as (a+)+ fails to match, the engine revisits every earlier choice point and tries each alternative split in turn. Nested quantifiers multiply the number of revisits, which is why a short input can take a long time to process when a pattern like (a+)+$ runs against a long run of the letter a. The MDN guide to regular expressions calls this catastrophic backtracking and recommends keeping every quantifier on a single token, the way a+ does. Greedy quantifiers consume as much as they can before giving characters back, while lazy ones such as a+? stop as soon as possible. Both return the same match, but they explore different routes, so the choice can affect how much work the engine does.

Aim for patterns that match in a single pass, and test them here before shipping.

Use cases

Validating user input is the most common job. An email address, a URL, a phone number, or an identifier can be checked against a pattern before a form is accepted or a request is sent. A capture group turns that one verdict into several, so the same match can return the local part and the domain of an address at once. The match index and the group breakdown are especially useful when you parse log lines or extract fields from structured text, because they show exactly which characters each part of the pattern consumed, down to the position where each slice began.

Debugging a pattern here is often faster than rewriting it blind.

When a pattern matches too much or too little, change a flag and watch the result update instantly. The index of each match makes the boundary visible, so you can see whether the pattern stopped too early or reached too far. Note that the JavaScript RegExp syntax follows the ECMAScript specification, so extensions from other dialects, such as Perl-compatible regular expressions, may not be valid here. If the pattern is destined for another language, consult that language's own regular expression documentation before relying on a feature this page rejects.

Troubleshooting

• “Invalid regular expression”: unescaped special characters or an unsupported flag combination. Check the flagged hint next to the pattern field for the character the constructor rejected.
• Page freezes: nested quantifiers such as (a+)+ trigger catastrophic backtracking, where the engine retries a huge number of splits. Rewrite the pattern with a single quantifier per token.
• No highlights: add the g flag. Without it only the first match is shown.
• Unexpected empty matches: zero-width patterns like a* match empty spans, which the tester marks with a thin bar.
• Unicode surprises: astral-plane characters such as emoji are composed of two code units. The u flag makes the engine treat them as single characters.
• Backslash confusion: inside a JavaScript string the pattern \d must be written as "\d". The tester accepts the raw form you type, so when you copy a pattern into code, double the backslashes.
• Group references: a backreference such as
refers to the first capture group, while (?<name>...) defines a named group that you later reference as \k<name>. The results panel lists both forms.