Regex Tester
Test and debug regular expressions with live match highlighting, match list, and capture group details. All client-side.
Common Patterns
Frequently Asked Questions
g— Global: find all matches, not just the first.i— Case-insensitive:Amatchesa.m— Multiline:^and$match start/end of each line.s— DotAll:.matches newline characters too.
grep, sed, awk). The theory is based on formal language theory — a regex defines a regular language recognizable by a finite automaton.. matches any character except newline; * zero or more; + one or more; ? zero or one (optional); ^ start of string; $ end of string; [abc] character class (a, b, or c); [^abc] negated class (anything except a, b, c); a|b alternation (a or b); {n,m} between n and m repetitions; \d digit, \w word character, \s whitespace; () capturing group; \ escapes special characters.*, +, ?, {n,m}) match as much as possible while still allowing the overall pattern to succeed. Lazy quantifiers (*?, +?, ??, {n,m}?) match as little as possible. Example: against the string <b>bold</b>, the pattern <.*> (greedy) matches the entire string, while <.*?> (lazy) matches only <b>. Use lazy quantifiers when parsing HTML-like content where you want to stop at the first closing delimiter.() match and capture the enclosed pattern as a numbered group (group 1, 2, …) that can be back-referenced or extracted. Non-capturing groups (?:) group a sub-pattern for precedence or quantification but do not save the match. Named groups (?<name>) work like capturing groups but accessible by name. Use non-capturing groups when you need grouping but don't need the captured value — this is slightly faster and avoids polluting the match array. Example: (?:https?|ftp) groups alternatives without capturing.(?=...) asserts that the following characters match a pattern without consuming them. Negative lookahead (?!...) asserts they do not match. Lookbehind (?<=...) asserts the preceding characters match. Negative lookbehind (?<!...) asserts they do not. These are zero-width assertions — they check a position but do not advance the match cursor. Example: \d+(?= dollars) matches a number only if followed by " dollars" without including " dollars" in the match.[^@\s]+@[^@\s]+\.[^@\s]+ — simple and sufficient for most use cases (RFC 5322 compliance requires a much more complex pattern). URL: https?://[^\s<>"]+. Phone (US): \+?1?\s?\(?\d{3}\)?[\s.\-]?\d{3}[\s.\-]?\d{4}. IPv4: (?:\d{1,3}\.){3}\d{1,3}. Date (YYYY-MM-DD): \d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]). These are practical patterns — for critical input validation, always combine with server-side logic.(a+)+b tested against aaaaaac — the engine tries every combination of how to split the as between the inner and outer group. Avoidance techniques: avoid nested quantifiers ((.+)+), use atomic groups or possessive quantifiers (where supported), be specific in character classes (use [a-z] instead of .), and test against adversarial inputs. Tools like recheck can statically detect vulnerable patterns.(?P<name>), JavaScript uses (?<name>). Recursive patterns — PCRE supports (?R) for recursive matching; JavaScript does not. Conditionals — PCRE supports (?(condition)yes|no); JavaScript does not. Unicode — JavaScript requires the u flag for full Unicode support; PCRE has its own Unicode mode.. ^ $ * + ? { } [ ] \ | ( ). For example, to match a literal period use \. (without the backslash, . matches any character). To match a literal backslash, use \\. To match a literal (, use \(. Inside a character class [], most special characters lose their special meaning — only ], \, ^ (at start), and - (between characters) need escaping within [].About This Regex Tester
This free regex tester lets you test JavaScript regular expressions against any input string in real time. Enter a pattern, choose flags (g, i, m, s, u), and see all matches highlighted as you type — along with capture group values and match indices.
Regular expressions are powerful but easy to get wrong. Testing a pattern interactively against real input data prevents incorrect matches or missed edge cases before the pattern is deployed in production code.
When to use this tool
- Debugging a regex pattern before adding it to production code
- Checking capture group indices and named groups
- Testing case-insensitive or multiline patterns
- Validating email, phone number, or date format patterns
Standards & References
How the Regex Tester Works
Testing a regex is a three-step pipeline from pattern compilation to highlighted results.
Compile Pattern
The pattern string and flags are passed to new RegExp(pattern, flags). Any syntax error (unclosed group, invalid escape sequence, etc.) is caught immediately and shown as a readable error message.
Find All Matches
String.matchAll(regex) returns an iterator of all matches including their index position, full match string, and all named/numbered capture groups — even for zero-length assertions.
Highlight & Tabulate
Each match is wrapped in a color-coded <mark> in the test string view. The match table shows every match's index, full text, and capture groups for detailed inspection.
Common Use Cases
Input Validation Patterns
Test email, phone number, postal code, IP address, and URL validation regexes against real-world edge cases before embedding them in server-side or client-side validation code.
Log File Parsing
Extract timestamps, IP addresses, HTTP methods, status codes, and user agents from Apache/Nginx access logs or application logs using capture groups. Test the pattern against sample lines before running it at scale.
Text Extraction
Pull structured data (prices, dates, order numbers, citations) from unstructured text. The match table shows exactly what each capture group extracted, making complex multi-group patterns easy to debug.
Search and Replace
Build the match half of a String.replace() or sed substitution. See exactly what will be replaced before applying the pattern to real data or a production script.
Security Rule Patterns
WAF rules, router constraints, and middleware filters use regex to allow/deny paths and parameters. Test the pattern against both valid and malicious inputs to ensure it allows the right things and blocks the rest.
Learning Regex Syntax
The Common Patterns library shows ready-made regexes for email, URL, IP, date, UUID, and more. Use them as starting points, modify them, and observe how each change affects the match results in real time.
Related Developer Tools
Related Articles
View all articles
Regex Readability: How Verbose Mode and Named Capture Groups Turn a Mystery Into Documentation
Two regexes can match identical strings while one takes 30 seconds to understand and the other takes 10 minutes — and the difference is almost always structural, not functional. Here's how verbose/extended mode adds comments and whitespace to patterns, why named capture groups document intent within the pattern itself, a mental library of common recognizable patterns, and when a single complex regex should be replaced with simpler sequential operations instead.
Named Capture Groups, Lookahead, and Lookbehind: Modern Regex Features That Make Patterns Readable
Named capture groups turn regex matches from numbered tuples into readable dictionaries. Lookahead and lookbehind assertions match positions without consuming characters. Here's the modern regex feature set — named groups, non-capturing groups, all four assertion types — with practical patterns for log parsing and URL extraction.
ReDoS: How Catastrophic Backtracking in a Single Regex Can Take Down a Server
A single regex with a crafted input knocked Stack Overflow offline for 34 minutes and caused a global Cloudflare outage. Here's how catastrophic backtracking works, which patterns are vulnerable, how to test for ReDoS, and how to write safe alternatives.
Regex Patterns Every Developer Should Have: A Practical Reference
A practical reference of the regex patterns developers actually need — email, URL, UUID, IP address, dates, semver, hex colours, slugs, and more — with edge cases and caveats for each.
Regex Tester — Write & Debug Regular Expressions with Live Highlighting
Learn how to write and debug regular expressions using a live tester — with syntax reference, real examples for email validation, log parsing, and URL extraction, and tips on greedy vs. lazy matching.
