Regex Tester
Test regular expressions against sample text. Highlight matches, inspect groups, and toggle flags.
How to use Regex Tester
- 1Enter a pattern
Type your regex pattern and toggle flags (g, i, m, s, u).
- 2Add test text
Paste the text you want to match against.
- 3Inspect matches
All matches highlight in the text. Capture groups list below.
About Regex Tester
Regular expressions are powerful but unforgiving — a single misplaced escape, a greedy quantifier where lazy was needed, or a forgotten flag can make a pattern silently match the wrong things. Worse, they fail silently: the regex compiles, runs, and returns no matches when it should have found dozens. A live regex tester gives you instant visual feedback: paste your pattern, paste sample input, and see exactly which substrings match.
Utilify uses the JavaScript (ECMAScript) regex engine — the same one your code runs against in the browser or Node.js. Capture groups, named groups, lookahead, lookbehind, and Unicode property escapes all behave as they would when you call .match() or .exec() in your own code. Toggle the standard flags (g, i, m, s, u) to test variants without re-typing.
The flags change everything, and they are the most common source of confusion. The "g" (global) flag finds every match instead of just the first; "i" makes matching case-insensitive; "m" (multiline) makes "^" and "$" match at line boundaries rather than only at the start and end of the whole string; "s" (dotAll) lets "." match newline characters; and "u" enables full Unicode mode. Flipping these on and off here is the fastest way to understand why a pattern that "should work" is not behaving.
Capture groups are the other half of practical regex work. Parentheses create numbered groups you can pull out of each match, and "(?<name>...)" creates named groups that are far more readable in replacement strings and code. The tester lists every group it captures per match, so you can confirm you are extracting exactly the right slice — the date out of a log line, the domain out of a URL, the version out of a tag — before you wire the pattern into your application.
One practical caution: poorly written patterns with nested quantifiers can trigger catastrophic backtracking, where the engine explores an exponential number of paths — in our measurements, each added input character doubled the runtime. This tester runs matching in a background Web Worker with a 2-second timeout, so a pattern that blows up is stopped and flagged instead of freezing the page. When that happens, simplify the ambiguous quantifier or anchor the pattern more tightly; our ReDoS write-up on the blog walks through measured examples and the fixes.
JavaScript regex vs PCRE vs Python — flavor differences that bite
This tester runs the real JavaScript engine, so patterns behave exactly as they will in Node or the browser. If you are porting a pattern from another language, these are the differences that actually matter:
| Feature | JavaScript (this tool) | PCRE (PHP, Perl) | Python re |
|---|---|---|---|
| Lookbehind (?<=…) | Yes (ES2018+) | Yes | Fixed-width only |
| Named groups | (?<name>…) | (?P<name>…) and (?<name>…) | (?P<name>…) |
| \d \w \s and Unicode | ASCII; use /u flag with \p{…} for Unicode | ASCII by default | Unicode by default |
| Possessive quantifiers a++ | Not supported | Yes | Python 3.11+ only |
| Inline modifiers (?i) | Not supported — use flags | Yes | Yes |
A pattern that works here is guaranteed to work in Node and every modern browser — but test again before shipping it to grep, Python, or your database engine.
When to use Regex Tester
- Validating input formats
Test email, phone, or postal-code patterns against real-world samples.
- Log parsing
Develop the regex you will use to extract structured fields from server logs.
- Find-and-replace prep
Verify a substitution pattern matches only what you intend before running it across a codebase.
Examples
Email Alice at [email protected] or Bob at [email protected]
Pattern: \b\w+@\w+\.\w+\b with the g flag.
Regex mistakes this tester surfaces immediately
- Greedy matching grabbing too much
Quantifiers are greedy by default: <.+> on "<b>bold</b>" matches the entire string, not just <b>. Use a lazy quantifier (.+?) or, better, a negated class like <[^>]+> which is both correct and faster.
<.+> on "<b>bold</b>" → matches <b>bold</b> <[^>]+> on "<b>bold</b>" → matches <b> - Unescaped dots
A bare . matches almost any character, so version\.1 style patterns silently match "version-1" and "versionX1" too. Escape literal dots in versions, IPs, and domain names: \.
- Catastrophic backtracking
Nested quantifiers like (a+)+$ can take exponential time on non-matching input — a classic ReDoS vector; in our measurements each added character doubled the runtime. This tester runs matching in a Web Worker with a 2-second timeout, so a pattern that backtracks catastrophically gets killed and flagged instead of freezing the page — making it a safe place to catch these before they reach production.
- Stateful /g regexes
A regex with the g flag keeps lastIndex between calls, so calling .test() twice on the same string can return true, then false. Reset lastIndex or drop /g when you only need a boolean check.
- Anchors without the m flag
By default ^ and $ anchor to the ends of the whole string, not each line. Multi-line input needs the /m flag for per-line anchoring — forgetting it is the usual reason a "working" pattern matches nothing in a log file. Paste a two-line sample into the tester above and toggle /m to watch the match set change instantly.
Frequently asked questions
Which regex flavor is this?+
JavaScript (ECMAScript) — the same regex engine built into your browser and Node.js, so behavior matches what your code will do.
Does it handle very large inputs?+
Up to a few MB comfortably. Matching runs in a background Web Worker with a 2-second timeout, so a pathological regex (catastrophic backtracking) is stopped and flagged instead of hanging the page.
Why does my pattern say it timed out?+
The pattern took more than 2 seconds to run against your test string, which almost always means catastrophic backtracking — typically a nested quantifier like (a+)+ or overlapping alternation meeting an input that nearly matches. Simplify the ambiguous part or anchor the pattern; the error links to our ReDoS write-up with measured examples and fixes.
What do the g, i, m, s, and u flags do?+
"g" finds all matches, "i" is case-insensitive, "m" makes ^ and $ match at line breaks, "s" lets "." match newlines, and "u" enables full Unicode mode.
Can I use capture groups and named groups?+
Yes. Numbered groups "( )" and named groups "(?<name>...)" both work, and the tester lists every captured group for each match so you can confirm what you are extracting.
Is my pattern or test text uploaded?+
No. Everything runs locally in your browser — your patterns and sample data never leave your device.
Related tools
Format, beautify, and validate JSON online. Free, fast, runs entirely in your browser.
Validate JSON syntax online with clear error messages and line numbers. Free and private.
Encode and decode Base64 strings online. UTF-8 safe, browser-only — your data never leaves your device.
From the blog
We measured catastrophic backtracking in Node 20: /^(a+)+$/ takes 6.5 seconds at 30 characters and doubles with each one added. Why it happens, the outages it caused at Stack Overflow and Cloudflare, and how we patched our own regex tester.
JavaScript has 8 regex flags — g, i, m, s, u, y, d, and the newer v. Learn what each one really does, when you need it, and the bug each one quietly fixes.