Regex Tester
Test regular expressions with real-time matching, highlighting, and group extraction.
Testing a pattern before it reaches production
Type the pattern and the sample text above and matches highlight as you go. The value of doing this before shipping a validator is that a regular expression almost always does something slightly different from what its author intended, and the gap only shows up on input nobody thought about.
Test a pattern the way you would test a function: with the values that should match, the values that should not, and the awkward cases between them. A pattern that accepts everything you try is not proven correct: it may simply be missing an anchor.
Anchors, and the bug that hides without them
An unanchored pattern matches anywhere inside the string. A validator checking for digits with \d{3} happily accepts abc123xyz, because three digits do appear somewhere. Add ^ at the start and $ at the end and the pattern must describe the whole value.
This is the single most common validation defect involving regular expressions, and it is invisible until someone tries a value with extra text around the valid part. Any input-validation test set should include a valid value with a prefix and the same value with a suffix.
Common patterns and what they get wrong
| Goal | A workable pattern | The catch |
|---|---|---|
| Email, pragmatic check | ^[^@\s]+@[^@\s]+\.[^@\s]+$ | Deliberately loose. Full RFC compliance is not achievable in a readable regex |
| IPv4 address | ^(\d{1,3}\.){3}\d{1,3}$ | Accepts 999.999.999.999; range checking needs real logic |
| UUID | ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ | Case-sensitive unless you add the i flag |
| ISO date | ^\d{4}-\d{2}-\d{2}$ | Accepts 2026-13-45; a regex cannot validate a calendar |
| Whole number | ^-?\d+$ | Leading zeros and huge values still need separate checks |
The pattern behind all of these: a regular expression describes shape, not meaning. It can tell you a string looks like a date and cannot tell you the date exists. Use it as a cheap first filter and validate semantics in code.
Why email validation by regex is a trap
The full grammar for an email address permits quoted strings, comments and addresses with no dot in the domain, so a strictly correct pattern is thousands of characters long and still cannot tell you the mailbox exists. Strict patterns in the wild routinely reject valid addresses, plus-tag addressing, new long top-level domains, apostrophes in names, and every rejection is a real user who cannot sign up.
The practical approach is a loose shape check plus a confirmation email, and a test set that includes user+tag@example.com, an address with a long modern top-level domain, and one with a non-Latin local part.
Greedy, lazy, and catastrophic backtracking
Quantifiers are greedy by default: <.*> against <a>text</a> matches the entire string, not the first tag. Adding a question mark makes it lazy: <.*?> stops at the first closing bracket. Mixing these up produces a pattern that works on one example and fails on two.
The security-relevant case is worse. Nested quantifiers such as (a+)+$ can make a backtracking engine explore an exponential number of paths, so a crafted input of a few dozen characters locks a thread for minutes. That is ReDoS, a denial of service through a regular expression, and it is a genuine finding when a user-supplied string is fed to a pattern like that. If a validator hangs on a long input, you have found one.
Flags, briefly
g: find every match rather than stopping at the first.i: ignore case, which is what most validators actually want.m: make^and$match at line boundaries rather than only at the ends of the string. This is the flag people forget when a pattern behaves oddly on multi-line input.
Matching runs in your browser, so sample data pasted from a real system stays on your machine.
Frequently asked questions
Why does my regex match more than expected?
Either it is unanchored, so it matches a substring anywhere in the value, or a quantifier is greedy and is consuming as much as it can. Add ^ and $ for validation, and use a lazy quantifier when you want the shortest match.
What is the best regex for validating an email address?
There is no correct one. Use a loose check that the value contains a local part, an at sign and a domain with a dot, then confirm the address by sending mail to it. Strict patterns reject valid addresses, and rejected sign-ups are more expensive than a loose filter.
What is catastrophic backtracking?
A pattern with nested quantifiers can force the engine to try exponentially many ways of matching a failing input, so a short crafted string consumes minutes of processing. When such a pattern is applied to user input it is a denial-of-service vulnerability, usually reported as ReDoS.
Are regular expressions the same in every language?
No. JavaScript, Python, Java, Go and PCRE differ on lookbehind, named groups, Unicode property escapes and more. A pattern verified in a browser tool should be re-checked in the language that will run it before you rely on it.
Should I use a regex to parse HTML or JSON?
No. Both are nested structures and regular expressions cannot express nesting reliably. Use a parser. A regex over HTML works on the example in front of you and breaks on the next document.
How do I test a regex properly?
Give it three sets of input: values that must match, values that must not, and edge cases, empty string, whitespace only, a valid value with text around it, a very long value, and non-Latin characters. A pattern that has only been tried against examples it was written for has not been tested.