Regex Tester & Debugger
Test a regular expression against real text and see every match, capture group, and named group as you type. Invalid patterns show the exact JavaScript error instead of failing silently. Runs entirely in your browser.
Last updated: 2026-08-30
Pattern
g all matches · i ignore case · m ^$ match each line · s dot matches newline · u unicode · y sticky
Quick presets
Result
3 matches
| # | Match | Span | Groups |
|---|---|---|---|
| 1 | 2026-01-30 | 14–24 | 1: 2026 2: 01 3: 30 year: 2026 month: 01 day: 30 |
| 2 | 2026-02-28 | 30–40 | 1: 2026 2: 02 3: 28 year: 2026 month: 02 day: 28 |
| 3 | 2027-11-02 | 59–69 | 1: 2027 2: 11 3: 02 year: 2027 month: 11 day: 02 |
Key Features
- Live matching: results update as you type — no button to press, no round trip.
- Real error messages: an invalid pattern shows the actual JavaScript engine error, so you can see exactly why it failed instead of guessing.
- Capture and named groups: every match lists its numbered groups and any
(?<name>...)named groups separately. - Match positions: each result shows its exact start and end index in the subject text.
- Replacement preview: see the result of
String.replace()with$1and$<name>references before you commit to it. - Fully private: the pattern and your test text never leave your browser.
How to Use This Regex Tester
- Type or paste your regular expression into the Pattern field. Leave off the surrounding slashes — just the expression itself.
- Set your flags. Use
gto find every match rather than only the first, andifor case-insensitive matching. - Paste the text you want to match against into the Test string box.
- Read the highlighted output. Matched spans are shaded, and the table below lists each match with its position and captured groups.
- Optionally add a replacement string to preview a find-and-replace before running it in your own code.
Why Test a Regular Expression Instead of Reading It?
Regular expressions are unusually easy to get subtly wrong. A pattern can look completely correct, compile without complaint, and still match the wrong thing — or nothing at all. Greedy versus lazy quantifiers change what .* captures. Group numbering shifts the moment you add a bracket. An unescaped dot quietly matches every character rather than a literal full stop. None of these produce an error; they produce a pattern that works on your three test inputs and fails on the fourth.
That is why running a pattern against real text beats reasoning about it. Seeing the actual matched spans, the actual group contents, and the actual count tells you in seconds what careful reading often gets wrong. It is also the fastest way to understand a regex somebody else wrote: paste it in with a representative sample and watch what it selects.
This tester runs on your browser's own JavaScript engine, which means the behaviour you see here is exactly the behaviour you will get in Node.js or in front-end code — same engine, same semantics, no translation layer. Because everything is local, you can safely test patterns against log lines, customer records, or anything else you would rather not paste into a hosted service.
Frequently Asked Questions
Is my pattern or test data sent anywhere?
No. Matching runs entirely in your browser using the native RegExp engine. Nothing is uploaded, logged, or stored, so it is safe to test against production log samples or sensitive strings.
Which regex flavour does this use?
JavaScript (ECMAScript), because it runs on your browser's built-in engine. That makes it exact for JavaScript and TypeScript work. Python, PCRE, Go, and Java differ in places — most visibly in named-group syntax, lookbehind support, and whether \d and \w are Unicode-aware.
Why does my pattern only find the first match?
You are missing the g (global) flag. Without it, JavaScript stops after the first match. Add g to the flags field and every match will be highlighted.
How do I use named capture groups?
Write them as (?<name>...), for example (?<year>\d{4}). Named groups appear by name in the Groups column, and can be referenced in a replacement string as $<name>.
What does “Invalid regular expression” mean?
The pattern could not be compiled at all. The most common causes are an unclosed group or character class, a quantifier such as * or + with nothing before it, or a stray backslash at the end. The exact engine error is shown so you can pinpoint it.
Can a regular expression be slow or dangerous?
Yes. Patterns with nested quantifiers such as (a+)+ can take exponential time on certain inputs, a problem known as catastrophic backtracking or ReDoS. If the page becomes unresponsive while typing a pattern like that, simplify the nesting — usually one of the two quantifiers is redundant.
Does it work offline?
Yes. Once the page has loaded you can disconnect entirely and keep testing patterns, since no network requests are involved.
Is there a limit on the amount of text?
There is no hard cap, but matching happens on the main thread, so extremely large inputs combined with a complex pattern may briefly freeze the page. For very large files, test against a representative sample first.