Regex Tester
Test regular expressions with sample text. Find matches, test patterns, and debug regex with real-time match highlighting and capture-group details.
Sample Patterns
Pattern & Test Input
Match Results
No Test String
Enter a pattern and test string in the left panel to see results
About Regex Tester
An advanced regular expression testing tool that allows you to test, debug, and validate regex patterns against sample text in real-time. This tool provides live feedback, match highlighting, and capture-group details to help you perfect your regular expressions before implementing them in your code.
Why use a Regex Tester?
Regular expressions can be complex and error-prone, making it essential to test them thoroughly before deployment. This tool saves development time by providing live visual feedback on pattern matches, helping you identify issues early and understand how your regex behaves with different input scenarios.
Who is it for?
Ideal for developers, data analysts, system administrators, and anyone working with text processing, data validation, or string manipulation. Perfect for those learning regex syntax or experienced developers who need to quickly test and refine complex pattern matching expressions.
How to use the tool
Enter your regular expression pattern in the regex input field
Add your test text in the sample text area to test against
View real-time matches highlighted in the text as you type
Edit the flags field (g global, i case-insensitive, m multiline, u unicode, y sticky) as needed
Review the match list with each capture group's value and debug any issues with your pattern
Frequently Asked Questions
How do I test a regex pattern?
Type your regex into the pattern field (no surrounding slashes needed), paste your test text into the Test String area, and the tool tests as you type (the Test Pattern button re-runs it). It highlights matches in the text and lists each match with its capture groups (numbered and named) and values; hover a highlight to see its position. Set flags in the flags field: g (global), i (case-insensitive), m (multiline), u (unicode), y (sticky); other valid JavaScript flags such as s (dotAll) can be typed too. The tool uses your browser's JavaScript (ECMAScript) regex engine only — there is no PCRE, Python or Go mode. Test edge cases: empty strings, unicode characters, leading/trailing whitespace, multi-line input.
What's the difference between PCRE and JavaScript regex?
PCRE (Perl-Compatible Regular Expressions) is the richer feature set — recursion, conditional patterns, named subroutines, possessive quantifiers, backreferences forward and back. JavaScript regex (ECMAScript) is more constrained: no recursion, no conditional patterns, no possessive quantifiers, and lookbehind and Unicode property escapes only since ES2018. Practical impact: a regex that works in PHP (PCRE) or Python (close to PCRE) may fail in JavaScript. JavaScript-specific points: the sticky (y) flag, dotAll (s flag, added late), and named groups `(?<name>...)`. This tool only tests JavaScript patterns, using your browser's own engine, so it can't tell you whether a pattern works in PCRE, Python or Go.
How do I match an email/phone/URL with regex?
Don't reach for complex regexes for these. Email validation per RFC 5322 is famously a 6,425-character regex — use the [Email Validator](/tools/email-validator/) tool instead. Phone numbers vary by country and format — use a library like libphonenumber. URLs have many valid variations — use a URL parser. When you really need a regex (logs, ad-hoc filtering), use forgiving approximations: emails as `/^[^\s@]+@[^\s@]+\.[^\s@]+$/`, URLs as `/^https?:\/\/[^\s]+$/`, phones as `/^\+?[0-9\s().-]{7,}$/`. Test the regex against real edge cases — international names, IPv6 URLs, parenthesized phones. The 80/20 rule applies: simple regex covers most cases, hard cases need real parsers.
Why does my regex work in Python but not JavaScript?
Most common causes: (1) Lookbehind — JavaScript only supports it since ES2018, and not all browsers/Node versions are caught up. (2) Named groups syntax — Python uses (?P<name>...), JavaScript uses (?<name>...). (3) Character class shortcuts — \d in some engines includes Unicode digits, in others only [0-9]. (4) Unicode property escapes — \p{L} requires the u flag in JavaScript. (5) Possessive quantifiers — *+, ++, ?+ work in PCRE/Java, not JavaScript. This tool runs your pattern in your browser's JavaScript engine, so an error or different result here points to one of these differences; it has no engine switch for comparing against Python. Pin your runtime version when shipping; older Node and old browsers have older regex engines.
Is online regex testing safe?
Yes. The tool runs entirely in your browser — your pattern and test inputs never leave your device. No logging. Verify in DevTools' Network tab: testing produces no HTTP requests with your data. Matching runs in a background worker with a 1-second time limit, so a catastrophically bad regex (deeply nested quantifiers like `(a+)+b` against long inputs) that would cause exponential backtracking (ReDoS, Regular Expression Denial of Service) is stopped and reported as 'Pattern took too long (possible catastrophic backtracking)' instead of freezing your tab. The limit applies to this tool only; it doesn't make such a pattern safe to ship.
What is ReDoS and how do I avoid it?
ReDoS (Regular Expression Denial of Service) happens when a regex's worst-case backtracking explodes exponentially on certain inputs. Classic vulnerable patterns: `(a+)+b`, `(a|a)*b`, `(.*a)*x`. Against a 30-character malicious input, these can take minutes to billions of years to evaluate. Avoid: nested quantifiers (a+)+, alternation with overlapping branches (a|a), unbounded greedy matches followed by required suffix. Prefer: atomic groups (?>...) (PCRE/Java), possessive quantifiers ++ (PCRE), or simple non-overlapping alternatives. In production, use a regex engine with backtracking limits or set timeouts. ReDoS is OWASP A05:2021 (Security Misconfiguration) when user input becomes regex input.
What's the difference between capture groups and non-capture groups?
(...) is a capture group — the matched substring is stored and can be referenced (by $1 in JavaScript replacement, \1 in PCRE, or by name with (?<name>...)). (?:...) is a non-capture group — same grouping behavior for alternation and quantifiers, but the matched substring isn't stored. Use non-capture when you need to group for syntactic reasons (apply a quantifier to multiple chars, alternate between sub-patterns) but don't need the captured value. Performance: non-capture groups are slightly faster because the engine doesn't allocate the capture buffer. Stylistic: use non-capture by default; only switch to capture when you actually need the value.
How do I use regex for input sanitization?
Generally don't — for security-sensitive sanitization (preventing XSS, SQL injection, command injection), use context-specific encoding/escaping libraries, not regex. Regex-based sanitization is famously incomplete: `"<script>alert(1)</script>".replace(/<script>/i, "")` is bypassed by `<scr<script>ipt>`. Regex is appropriate for: (1) validation — accepting only known-good patterns ([a-z0-9_-]+ for usernames), (2) extracting structured data from logs, (3) feature flagging (does this string contain a specific marker). For sanitization, use the [XSS Payload Tester](/tools/xss-payload-tester/) and [User Input Sanitizer Tester](/tools/user-input-sanitizer-tester/) tools to verify your defenses, and use language-native escaping (htmlspecialchars, parameterized SQL queries, shell argument arrays).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.