Test and Debug Regular Expressions
Test a regex pattern and see live matches, groups, and flags as you type it.
Pattern and sample stay on your device
Nothing to delete afterwards
Safe for real production samples
Works in every modern browser
How it works
- 1
Enter your pattern
Write it in the field and set the flags you intend to use in production.
- 2
Paste representative text
Include the awkward cases and the strings that should not match at all.
- 3
Read the matches and groups
Check both what was found and what was skipped before you take the pattern anywhere.
Why use this tool
Every match highlighted live
See what the pattern actually catches as you type it, instead of guessing from the syntax.
Capture groups broken out
Numbered and named groups listed per match, which is where most patterns are actually wrong.
Flags you can see
Global, case-insensitive, multiline, and dotall shown explicitly rather than buried in a delimiter.
Test the non-matches too
Paste the strings that must be rejected alongside the ones that must match — that is the half people skip.
Nothing is uploaded
The pattern and the sample text stay in your browser, and real log lines never reach a server.
Free, no account
No signup, no watermark, no cap on how much you test.
A pattern that matches your examples is not a pattern that works
Almost everyone tests the same way: write the expression, paste in three strings it is supposed to catch, see them highlighted, ship it. That confirms the pattern is not completely broken and tells you nothing about the failure that will actually bite. The interesting question is not what it matches but what it also matches — the input you never thought of that slips through, and the valid input it silently rejects. A pattern for a phone number that works on four examples will meet an international prefix, an extension, or a space in an unexpected place. So the discipline worth adopting is to paste in the strings that must be rejected, deliberately, alongside the ones that must be caught, and check both lists every time the pattern changes.
Some patterns can hang the process that runs them
This is the failure mode that turns a regular expression into an outage, and it is worth knowing because it is invisible until it happens. Most engines match by backtracking: when a branch fails they retreat and try another. With nested quantifiers — a repeated group that itself repeats, of the shape `(a+)+` — the number of arrangements to try grows exponentially with the input length. On a matching string it finishes instantly; on a string that *nearly* matches and then fails at the end, it can run for longer than the universe has existed. That is a denial-of-service vector when the pattern is applied to user input, and it has taken down large services: both Cloudflare and Stack Overflow have published post-mortems attributing a global outage to exactly this. If your pattern has a quantifier inside a quantified group, test it with a long non-matching string before it goes anywhere near production.
There is no single regular expression language
The syntax looks portable and it is not. JavaScript, PCRE as used by PHP and Perl, Python, Java, .NET, and the POSIX tools each implement a different dialect, and patterns move between them with silent changes in meaning. Lookbehind is a common trap: it has been in PCRE for decades and only reached JavaScript recently, so a pattern that works in your editor may fail in a browser. Go and several other systems use RE2, which is a different design entirely — it guarantees linear time, so the catastrophic backtracking above is impossible, but it achieves that by dropping backreferences and lookaround completely. Named group syntax, Unicode property escapes, and even what `\d` includes vary. Test in the flavour you will deploy in, because passing here and failing there is otherwise the outcome.
Greedy by default, and the dot is narrower than you think
Two defaults account for a large share of patterns that behave oddly. Quantifiers are greedy: `.*` takes as much as it can and only gives back what it must, so `<.*>` applied to `<a><b>` matches the entire string rather than the first tag. Adding a question mark makes it lazy — `<.*?>` — and matches each tag separately, which is almost always what was intended. The second default is that the dot does not match a newline. That is invisible on single-line examples and becomes a mystery the moment the pattern meets a multi-line document and stops at the first line break; the dotall flag fixes it. A related pair is worth keeping straight: multiline changes what `^` and `$` mean, anchoring them to each line rather than the whole string, and it does nothing to the dot.
What not to use a regular expression for
The advice against parsing HTML with a regex is usually delivered as a joke, and the underlying reason is precise: HTML nests to arbitrary depth, matching an opening tag to its closing tag requires counting, and a regular expression has no memory to count with. It is not a matter of writing a better pattern — the class of language is wrong. Email addresses fail differently. The grammar in RFC 5322 permits quoted strings, comments, and characters nobody expects, so a genuinely conforming pattern runs to thousands of characters and still cannot tell you the only thing that matters, which is whether the address receives mail. The practical rule for both: use a real parser for structured markup, and for an address check that there is an `@` with something on each side, then send a confirmation message.
Why testing locally matters for this kind of text
The pattern itself is rarely sensitive. What you paste to test it usually is, because a regular expression is only worth testing against realistic input — which means real log lines with real addresses in them, an export of customer records you are trying to clean, a sample of production data you copied precisely because the synthetic examples were not catching the problem. That is the material that makes the test meaningful and the material you would not choose to hand to a third party. This tool runs the match in the page and transmits neither the pattern nor the sample, which you can confirm in the Network tab of your developer tools.
Common mistakes to avoid
- Testing only strings that should match. The failure that bites is the input you never thought of slipping through — paste the strings that must be rejected too, every time the pattern changes.
- Nesting a quantifier inside a quantified group. Shapes like `(a+)+` backtrack exponentially on a near-miss input, which is a denial-of-service vector that has caused documented global outages.
- Assuming the pattern is portable. Lookbehind, named groups, and Unicode escapes differ between JavaScript, PCRE, Python, and RE2 — test in the flavour you will deploy in.
- Forgetting that `.` does not match a newline. A pattern that works on one line stops at the first line break in a document; the dotall flag is what you want, not multiline.
- Parsing HTML or validating email with a regex. Nesting needs a counter a regex does not have, and a conforming email pattern still cannot tell you whether the address receives mail.
How it compares
| Aspect | This tool | Online testers | An editor’s find panel |
|---|---|---|---|
| Content sent to a server | Never | Usually yes | No |
| Capture groups broken out | Yes | Usually | Rarely |
| Flags shown explicitly | Yes | Usually | Partly |
| Works without a project open | Yes | Yes | No |
| Account or signup | Not needed | Sometimes required | Not needed |
| Price | Free | Free / paid tiers | Free / paid |
Features
Live highlighting
Matches marked in the sample text as the pattern changes, with overlapping detail on hover.
Named and numbered groups
Each capture listed per match, so you can see which group holds what.
All the common flags
Global, ignore-case, multiline, dotall, unicode and sticky, each toggled independently.
Match count and positions
How many hits and where they start, which matters when you are replacing rather than searching.
Syntax errors explained
An unbalanced bracket or a bad escape says what is wrong instead of silently matching nothing.
Handles long input
Whole log files can be pasted as the test subject without an upload.
Nothing to install
No editor, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Developers
Getting a pattern right against real sample data before putting it in code.
Data analysts
Building an extraction pattern for a messy column and seeing exactly what it misses.
System administrators
Checking a log-filtering expression against actual log lines rather than invented ones.
Anyone learning regular expressions
Watching what a pattern does as you change it, which is faster than reading about it.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.