Regular expression tester
- Runs in your browser
- No signup
- Formula shown below
- Reviewed
A regular expression tester runs a pattern against sample text and shows every match, its offset, and the contents of each capture group. The pattern /(\w+)@(\w+\.\w+)/ applied to "ada@example.com" produces 1 match with 2 capture groups: "ada" and "example.com". Matching here uses the browser's own JavaScript regular-expression engine.
How to use the regex tester
- 01
Enter your pattern
Type the regular expression source without the enclosing slashes. Matching runs live as you type.
- 02
Set the flags
Toggle g, i, m, s and u. Each button explains what the flag does when hovered, and the pattern display updates.
- 03
Paste your test text
Put representative sample text in the test pane, including the awkward cases you expect the pattern to reject.
- 04
Review the matches
Matches are highlighted in place, and each is listed with its offset and the contents of every numbered and named capture group.
- 05
Try a replacement
Enter a replacement string using $1, $2 or $<name> to reference groups, and see the substituted output immediately.
The formula
new RegExp(pattern, flags).exec(subject) repeatedly until null
- pattern
- The regular expression source, without the enclosing slashes.
- flags
- Modifiers: g global, i ignore case, m multiline, s dot-matches-newline, u unicode.
- capture group
- A parenthesised sub-pattern whose matched text is reported separately, numbered from 1.
- lastIndex
- The engine's position marker, advanced after each match so iteration progresses.
A zero-length match, which a pattern such as a* produces against text containing no a, does not advance the engine's position marker and will loop forever unless the position is nudged manually. That guard is implemented here, which is why a pattern matching the empty string returns cleanly rather than hanging the tab.
Worked example
- Pattern
- (\w+)@(\w+\.\w+)
- Flags
- gm
- Test string
- Contact: ada@example.com, grace@example.org
- Result
- 2 matches, each with 2 capture groups
The pattern looks for one or more word characters, an at sign, then a domain of word characters, a dot and more word characters. Against the sample it finds "ada@example.com" at offset 9 and "grace@example.org" at offset 26. Each match yields group 1 as the local part, "ada" and "grace", and group 2 as the domain, "example.com" and "example.org". The g flag is what makes the engine continue past the first match rather than stopping.
Frequently asked questions
What does the g flag do in a regular expression?
The global flag makes the engine find every match rather than stopping at the first. Without it, exec returns only the first match and replace substitutes only one occurrence. This tester forces the global flag on so the full match list can be shown, which is why the count may exceed what the same pattern returns without it in your own code.
What is a capture group?
A capture group is a parenthesised part of a pattern whose matched text is reported separately, numbered from 1 in the order the opening parentheses appear. Named groups use the syntax (?<name>...) and are reported by name as well. Non-capturing groups, written (?:...), group for structure without producing a result.
What is the difference between greedy and lazy matching?
Greedy quantifiers such as * and + take as much text as possible and then give characters back until the rest of the pattern fits. Lazy quantifiers, written *? and +?, take as little as possible and expand only as needed. Matching HTML tags with <.*> greedily swallows everything to the last angle bracket; <.*?> stops at the first.
What is catastrophic backtracking?
Nested quantifiers over overlapping alternatives, such as (a+)+b, can force the engine to try exponentially many ways to split the input before concluding there is no match. A few dozen characters can then hang a process for minutes. Because this is a real denial-of-service vector on servers, patterns applied to user input should avoid nested quantifiers.
Should regular expressions be used to validate email addresses?
Only loosely. The RFC 5322 grammar is far more permissive than most people expect, and a fully conforming pattern runs to hundreds of characters while still rejecting valid addresses. Checking for a single at sign with something before and after it, then sending a confirmation email, is more reliable than any pattern.
Do regular expressions work the same in every language?
No. This tester uses the JavaScript engine, whose syntax is close to PCRE but not identical. JavaScript gained lookbehind only in ES2018, has no possessive quantifiers or atomic groups, and requires the u flag for correct Unicode property handling. Python, Java, Go and PCRE all differ in named-group syntax and available features.
Is the test text sent anywhere?
No. Both the pattern and the subject text stay in this page, and matching runs on the browser's own regular-expression engine. Nothing is transmitted, logged or stored, and this site has no server-side code that could receive it, so testing a pattern against real log output or customer data is safe.
Sources
- ECMAScript specification — RegExp objects — Ecma International, TC39
- Regular expressions — syntax reference — Mozilla Developer Network
- Regular expression Denial of Service (ReDoS) — OWASP
Last reviewed: · Formula and sources verified by Syed Aqeel Ahmad Gillani. See the methodology for how every calculation is derived.