⚙️ Interactive Regex Builder & Tester
Test and debug regular expressions in real-time with group capture inspection, flag switches (g, i, m), and ready-to-use cheatsheet presets.
What Interactive Regex Builder & Tester Does
A regular expression describes a pattern of text. Testing one interactively matters more than it sounds, because regex fails quietly: a pattern that looks right will match slightly the wrong thing and you will not notice until it is in production, silently dropping every third record.
This runs the JavaScript engine, live, with matches highlighted in your test text and capture groups broken out. Highlighting is the point — reading a count of matches tells you far less than seeing which characters were consumed, especially when a greedy quantifier has swallowed more than you intended.
It also runs the match inside a Web Worker with a one-second limit. That is not decoration. Regex matching is synchronous and uninterruptible, so a pattern with nested quantifiers — the classic is (a+)+ — can backtrack exponentially and lock a browser tab solid on a few dozen characters of input. Running it in a worker means a runaway pattern gets terminated instead of taking the page with it.
That failure mode has a name, ReDoS, and it is a genuine denial-of-service vector when the pattern meets attacker-controlled input. If a pattern times out here, it will hang your server too.
How to Use Interactive Regex Builder & Tester
- Enter or choose a regular expression pattern and flags
- Type or paste your test string
- Inspect match count, index positions, and captured groups instantly
Formula Used by Interactive Regex Builder & Tester
The pieces, in one line
\d digit · \w word char · \s whitespace · . any · [abc] set · [^abc] not · ? 0-1 · * 0+ · + 1+ · {2,5} range · ^ start · $ end · \b boundary · (…) capture · (?:…) group · | or
- greedy vs lazy
- .* takes as much as possible; .*? takes as little. This is the most common cause of a pattern matching too much.
- \b
- a zero-width boundary between a word character and a non-word character — matches a position, not a character
- escaping
- inside a character class, most metacharacters are literal; outside it, . + * ? ( ) [ ] { } ^ $ | \ all need a backslash
Worked example
Extracting the year, month and day from 2026-09-08 with (\d{4})-(\d{2})-(\d{2}).
- \d{4} matches exactly four digits and the parentheses capture them as group 1
- The literal hyphen must match next, so 20260908 would not match
- Two more captured pairs give groups 2 and 3
Result: Group 1 = 2026, group 2 = 09, group 3 = 08. Note that this validates the shape, not the date — it happily accepts 2026-99-99.
Flags
| Flag | Effect |
|---|---|
| g | Global — find every match rather than stopping at the first |
| i | Case-insensitive |
| m | Multiline — ^ and $ match at line breaks, not just string ends |
| s | Dot matches newlines too |
| u | Unicode mode — needed for \p{…} property escapes and correct handling of characters outside the basic plane |
| y | Sticky — matches only at exactly lastIndex |
| d | Record start and end offsets for each capture group |
Patterns that hang, and why
Each of these is fine on matching input and catastrophic on input that ALMOST matches.
| Pattern | Problem |
|---|---|
| (a+)+$ | Nested quantifiers — the engine tries every way to split the a's before giving up |
| (\w+\s?)*$ | The same shape with a wider inner match |
| (a|a)*$ | Alternation of identical branches doubles the search space at every step |
| ^(\w+\.)*\w+@ | Common in hand-rolled email patterns; hangs on a long local part with no @ |
How to Read Your Result
Test the near-misses, not the matches
A pattern that matches your examples proves almost nothing. What finds bugs is input that nearly matches — a trailing space, a missing @, a doubled hyphen — because that is where greedy quantifiers and missing anchors show themselves.
Anchor unless you mean not to
Without ^ and $, a validation pattern matches anywhere in the string, so a "valid email" check will happily approve "nonsense user@example.com more nonsense". This is probably the single most common regex bug in production code.
Flavors differ
This is the JavaScript engine. Lookbehind, named-group syntax, Unicode property escapes and possessive quantifiers all vary between JavaScript, PCRE, Python, Go and .NET. Go's RE2 in particular has no backtracking at all, which makes it immune to the hangs above and also unable to express backreferences.
Do not parse HTML with it
Or JSON, or CSV with quoted fields, or any nested structure. Regular expressions cannot describe balanced nesting, so the pattern will work on your samples and fail on real data. Use a parser.
Limitations & Accuracy Notes
- JavaScript engine only. Patterns are not guaranteed to be portable to other languages.
- Matching stops after one second, so a legitimately expensive pattern over a large input may be cut off along with a genuinely catastrophic one.
- The first 500 matches are collected and the first 50 are listed in the table; all found matches are highlighted.
- Highlighting shows overlapping matches only once — regex matching does not produce overlaps, but a zero-length match has no visible extent.
- It tests the pattern you type against the text you provide. It cannot tell you whether that pattern is the right approach.
Frequently Asked Questions
How does the live regex tester work?
What common regex presets are included?
What is the difference between a greedy and a lazy quantifier?
What does a word boundary match?
What is the difference between a lookahead and a capture group?
Why are non-capturing groups worth using?
Should I use regex to parse HTML?
Is my pattern sent anywhere?
References & Further Reading
- MDN — regular expressions — The reference for the JavaScript syntax and flags this tool runs
- OWASP — regular expression denial of service — Why the timeout exists and what catastrophic backtracking costs in production