What is Regex Tester?
Regex Tester — A regex tester is a free utility that lets you write, test, and debug regular expressions against sample text with real-time match highlighting.
Loading your tools...
Test and debug regular expressions with real-time match highlighting, capture group inspection, and full flag support. Paste a pattern and a test string to see matches instantly.
Regex Tester: Enter a pattern and a test string to see matches highlighted instantly. The tool uses JavaScript syntax with all flags (g, i, m, s, u, y), and most standard patterns behave the same in Ruby and Python. View capture groups, match indices, and replacement results.
Loading Tool...
Regex Tester — A regex tester is a free utility that lets you write, test, and debug regular expressions against sample text with real-time match highlighting.
Enter your regular expression pattern in the regex input field.
Paste or type the test string you want to match against.
Toggle regex flags (global, case-insensitive, multiline) as needed.
Review highlighted matches, capture groups, and match indices — refine your pattern until it works correctly.
Build and test form validation patterns (email, phone, URL, password)
Create log parsing regex for extracting timestamps, IPs, and error codes
Design search-and-replace rules for text processing pipelines
Validate data extraction patterns before deploying to production
Debug why a regex pattern is not matching expected input
Regular expressions (regex) are a domain-specific language for pattern matching in text. Invented in the 1950s by mathematician Stephen Cole Kleene, they were first implemented in Unix tools like grep in the 1970s. Today, regex is built into every major programming language (JavaScript, Python, Java, Go, Rust, PHP, Ruby) and every text editor (VS Code, Sublime, vim, Emacs). A regex pattern describes what text looks like — not the exact text — letting you match, extract, validate, or replace based on structure.
| Pattern | Matches | Example |
|---|---|---|
. | Any single character (except newline) | c.t matches cat, cut, c8t |
\d | Any digit 0-9 | \d\d matches 42, 99 |
\w | Word char (a-z, A-Z, 0-9, _) | \w+ matches hello_world |
\s | Whitespace (space, tab, newline) | a\sb matches "a b" |
[abc] | Character class (a OR b OR c) | [aeiou] matches vowels |
[^abc] | Negated class (NOT a, b, or c) | [^0-9] = non-digit |
* | 0 or more (greedy) | a* matches "", "a", "aaa" |
+ | 1 or more (greedy) | a+ matches "a", "aaa" |
? | 0 or 1 (optional) | colou?r matches color/colour |
{n} | Exactly n | \d{3} matches 3 digits |
{n,m} | Between n and m (inclusive) | \d{3,5} = 3-5 digits |
^ / $ | Start / end of string (or line w/ m flag) | ^abc$ exact match |
(abc) | Capture group | (\d+)-(\d+) captures both |
(?:abc) | Non-capturing group | (?:ab)+ repeated ab |
(?<name>abc) | Named capture group | (?<year>\d{4}) |
a|b | Alternation (a OR b) | cat|dog |
(?=abc) | Positive lookahead | \d(?=px) = digit before px |
(?<=abc) | Positive lookbehind (ES2018+) | (?<=$)\d+ = price digits |
^[\w.-]+@[\w.-]+\.\w+$^https?://[^\s/$.?#].[^\s]*$^(\d{1,3}\.){3}\d{1,3}$ (basic; doesn't validate octets ≤ 255)^\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}$^\d{4}-\d{2}-\d{2}$^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&]).{8,}^[a-z0-9]+(?:-[a-z0-9]+)*$^\w{3,20}$^\d{13,19}$ (then Luhn check)\[([^\]]+)\]\(([^)]+)\)<[^>]+> (don't parse HTML with regex for real apps)By default, regex quantifiers (*, +, ?, {n,m}) are greedy — they match as much text as possible. Add a ? after them to make them lazy — match as little as possible. Example:
<.*> applied to <a>text</a> matches the ENTIRE string<.*?> matches just <a> first, then </a> separatelyUse lazy quantifiers when you want the shortest match. They're critical for parsing structured text like HTML tags, JSON values, or string-delimited tokens.
Some regex patterns can cause exponential runtime on certain inputs — this is called catastrophic backtracking. The engine tries every possible combination of matches, and on certain strings it explodes to seconds, minutes, or hours of CPU. The classic example: (a+)+b applied to aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac (note the trailing c, not b). It will hang for several seconds before failing.
Avoid: nested quantifiers like (a+)+, (a*)*, (a|aa)+. Mitigate: use possessive quantifiers (a++, not in JS), atomic groups ((?>...), not in JS), or rewrite to avoid ambiguity. This is a real security issue: ReDoS (Regular Expression Denial of Service) attacks exploit slow regex in production code. Always test regex with adversarial inputs.
| Feature | JavaScript | Python | PCRE / PHP |
|---|---|---|---|
| Lookbehind | ES2018+ (variable length OK) | Yes (fixed length only) | Yes |
| Named groups syntax | (?<name>...) | (?P<name>...) | (?<name>...) or (?P<name>...) |
| Atomic groups | No | No | (?>...) |
| Possessive quantifiers | No | No (use atomic group) | ++, *+, ?+ |
| Recursion | No | No (regex), yes (re2) | Yes (?R) |
| Unicode property classes | \p{...} with /u flag | Yes | Yes |
g=global, i=ignoreCase, m=multiline, s=dotAll, u=unicode, y=sticky