Regex Tester

Iterating on a regex by changing the pattern, switching tabs to your test runner, looking at the output, and going back to the regex is the slowest possible way to develop a pattern. The feedback loop should be one keystroke long; instead, it's often a thirty-second cycle that turns a five-minute task into thirty.

Paste your test text and your pattern, and matches highlight as you type. Capture groups appear named and indexed in a side panel. Pattern flags (g, i, m, s, u, y) toggle with checkboxes. Common problem patterns — backtracking issues, character class confusion, lookahead misuse — get flagged with explanatory hints rather than left for you to discover via slow execution.

Uses the JavaScript regex engine, which differs in subtle ways from PCRE, .NET, Python's re, and other dialects. Most patterns transfer cleanly; lookbehinds, named groups, and Unicode property escapes have engine-specific syntax differences worth checking before deploying to a different runtime.

The edit-test cycle for regex development is what makes tools like this useful. Without one, you write a pattern, paste it into your code, run the test or service, look at the output, and back to the editor — easily 30 seconds per iteration on a non-trivial pattern. With live highlighting, the cycle is one keystroke, and you can converge on a working pattern in 30 seconds total instead of 30 minutes. The capture-group panel matters too — for patterns extracting structured data (dates, IPs, ID formats), you need to see what each group captures, not just whether the overall pattern matches.

Worked example: building a regex to match US phone numbers in formats like (555) 123-4567, 555-123-4567, or 555.123.4567. Start with \(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}. Test against sample text containing all three formats plus some non-matches. Capture groups give you area code, prefix, and number separately. Add ^ and $ anchors if you want full-string match; remove them for substring extraction. Add the i flag if your text might have unusual casing (no, phone numbers are digits, but as a habit). The whole cycle takes a few minutes versus an hour of trial-and-error coding.

Limits worth flagging: catastrophic backtracking is a real performance failure in regex. Patterns like (a+)+b on input "aaaaaaaaaaa" force exponential time exploration of nested quantifiers. The tester flags suspicious patterns, but production regex engines vary in their protection against this. JavaScript's V8 has some safeguards; PCRE has more; .NET Framework historically had less. If you're processing untrusted input with user-supplied patterns, the threat is real (regex denial-of-service, ReDoS); for fixed patterns over fixed input, the risk is operational, not security.

The engine differences across languages are subtle but bite in production. JavaScript got lookbehind support in 2018 (ES2018), so (?<=foo)bar works in modern browsers but not older Node versions. Named groups (?<name>...) work in JavaScript and many engines but with slight syntax differences (Python uses (?P<name>...)). Unicode property escapes (\p{Letter}) require the u flag in JavaScript and have varying coverage elsewhere. For patterns destined for production in a non-JS language, test in that language's actual engine, not just in a JS-based tester. Most patterns translate; the edge cases are where surprises happen.