Regex Tester
Quick Access to Regex Tools
Go straight to the regex utility you need.
How to Use the Regex Tester
Enter your regex pattern
Enter your regex pattern.
Paste the test string
Paste the test string.
See matches highlighted in real-time
See matches highlighted in real-time.
Regex Tester — Test Regular Expressions Against Real Text
A regular expression that looks clean on paper can completely fall apart the moment it touches real input. Extra whitespace, Unicode characters, edge cases you never anticipated — these are the things that break patterns in production. Our Regex Tester gives you a browser-based sandbox where you can paste your pattern, feed it sample text, and watch every match light up in real time. No setup, no dependencies, no server round-trips.
The tool runs on JavaScript's built-in RegExp engine, which means patterns you test here work directly in any modern browser, Node.js environment, or anywhere you'd write JavaScript or TypeScript. If you're targeting PHP (PCRE), Python, or Java, the patterns are nearly identical — the core syntax is universal across all major engines.
How Regular Expressions Actually Work
At its core, a regex is a sequence of characters that defines a search pattern. The engine scans through your input text and tries to match that pattern at each position. When it finds a match, it returns the matched text and its position. Understanding this scan-and-match behavior explains why patterns sometimes produce more (or fewer) matches than you'd expect.
The basic building blocks include literal characters (which match themselves), metacharacters like . (any character), \d (digit), \w (word character), and \s (whitespace), and quantifiers like * (zero or more), + (one or more), ? (optional), and {n,m} (between n and m times). Anchors like ^ and $ don't match characters — they match positions at the start and end of a line (or string).
Common Flags and When to Use Them
Flags change how the entire pattern behaves. The g (global) flag is the one most people forget — without it, the engine stops after the first match. The i (case-insensitive) flag treats uppercase and lowercase as equivalent, which is essential when matching user input that might come in any case. The m (multiline) flag changes what ^ and $ mean: instead of matching the start and end of the whole string, they match the start and end of each line. The s (dotAll) flag makes the . metacharacter match newline characters too, which matters when your input spans multiple lines.
A practical tip: start with gm for most find-and-replace workflows. Add i when case shouldn't matter, and add s when you need to match across line breaks.
Real-World Patterns You Can Test Right Now
Email addresses: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,} handles the majority of real email formats. It's not RFC-perfect, but it catches 99% of what you'll encounter in the wild without producing absurd false positives.
Phone numbers (US format): \(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4} matches formats like (555) 123-4567, 555-123-4567, 555.123.4567, and 5551234567. The parentheses and separators are all optional.
URLs: https?:\/\/[^\s]+ is a simple way to grab HTTP and HTTPS URLs. The [^\s]+ part matches everything up to the next whitespace character, which works for most pasted text.
Dates (YYYY-MM-DD): \d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]) matches ISO-format dates and rejects impossible months like 13 or days like 32.
Debugging Tips When Your Pattern Doesn't Work
Most regex debugging comes down to a few recurring issues. Greedy vs. lazy matching is the big one: .+ grabs as much as possible, while .+? grabs as little as possible. If your match is swallowing more text than expected, try switching to the lazy variant. Unescaped special characters cause mysterious failures — if you want a literal dot, write \., not .. Missing anchors let the engine match partway through a string when you expected an exact match, or vice versa.
One trick that saves hours: break complex patterns into smaller pieces and test each one individually. Get the first part matching correctly, then add the next segment. Trying to write a 50-character pattern in one shot and debugging the whole thing at once is a recipe for frustration.
Common Regex Engines Compared
Not all regex engines are identical. JavaScript uses its own engine built into every browser and Node.js. Python offers two modules: re (basic) and regex (extended, with Unicode support). PHP uses PCRE2, which is one of the most feature-rich engines available. Java's java.util.regex is solid but lacks some conveniences like named backreferences. Go's regexp package uses RE2, which guarantees linear-time matching but doesn't support lookaheads or backreferences.
The core syntax — character classes, quantifiers, groups, alternation — is shared across all these engines. Where they differ is in advanced features. If you test a pattern here and it uses only basic syntax, it'll work everywhere. If you use lookaheads or backreferences, double-check that your target engine supports them.
Frequently Asked Questions
g (global) finds all matches instead of stopping at the first one. i makes the match case-insensitive, so [a-z] also matches uppercase letters. m (multiline) lets ^ and $ match at the start and end of each line, not just the whole string. s (dotAll) makes . match newline characters, which is useful when matching text that spans multiple lines. For quick testing, gm is a solid default.g flag when you expect multiple matches? Are anchors like ^ or $ restricting the match to positions you didn't intend? Try removing anchors temporarily to see if the pattern matches at all. Also check for case sensitivity — add i if your input might have mixed casing. Finally, make sure special characters like ., *, or ( are escaped with a backslash if you intend to match them literally.+, *, and {n,m} are greedy — they match as many characters as possible before backtracking. Adding a ? after a quantifier makes it lazy, matching as few characters as possible. For example, <.+> on <a> <b> matches the entire string, while <.+?> matches <a> and <b> separately.regex module has Unicode properties that JavaScript lacks, and some engines support features like possessive quantifiers or atomic groups that JavaScript doesn't. For basic to intermediate patterns, what works here works everywhere.\., a literal asterisk is \*, and a literal backslash is \\. The full list of characters that need escaping in most regex engines: . * + ? ^ $ ( ) [ ] { } | \ /. When in doubt, escape it — a backslash before a non-special character is simply ignored by most engines.(\w+)@(\w+), the first group captures the username and the second captures the domain. The tester shows each group's matched content separately. Capture groups are essential when you need to extract specific parts of a match or when using the pattern with find-and-replace tools (where you reference groups as $1, $2, etc.)..* will consume everything from the first match point to the end of the line. Try making quantifiers lazy with a trailing ?, or use more specific character classes like [^"]* instead of .* to match only up to the next quote. Another common cause is missing word boundaries — add \b around a word if you only want to match it as a standalone word, not as part of a longer string.(\w+)+ can cause catastrophic backtracking on non-matching input — the engine tries exponentially many combinations before giving up. Simpler patterns that achieve the same result, like \w+, are always preferred. As a rule of thumb: avoid nested quantifiers, prefer specific character classes over ., and use anchors to limit the search space.