RunToolRunRegex Tester
Test your regular expressions.
How to Test Regular Expressions
Enter your pattern
Type the regex with flags like g, i or m.
Paste test text
Add the sample text you want to match against.
See matches highlighted live
Every match lights up instantly as you edit the pattern.
Testing beats reading
A regular expression is dense enough that reading it rarely tells you what it does. Testing against real input — including the input you expect to fail — is how you find out. Most regex bugs are not misunderstood syntax but unconsidered cases: the empty string, a trailing space, a line break in the middle, an input twice as long as expected.
The habit worth building is to write the failing cases first. A pattern that matches what you want is easy; a pattern that also rejects what you do not want is the actual job.
Greedy and lazy quantifiers
By default, quantifiers take as much as possible and then give back only as needed. Applied to `<.*>` against a line containing two tags, that matches from the first `<` to the last `>` — everything, including what is between the tags.
Adding `?` makes a quantifier lazy, so `<.*?>` stops at the first `>` and matches each tag separately. This single character accounts for an enormous share of regex confusion, and swapping it is the first thing to try when a pattern matches far more than intended.
Catastrophic backtracking is a real hazard
Certain patterns take exponential time on inputs that nearly match. Nested quantifiers such as `(a+)+b` are the classic shape: against a long run of `a` with no `b`, the engine tries every possible division before concluding there is no match, and a forty-character input can hang for minutes.
On a server this becomes a denial-of-service vector, since one crafted request can occupy a whole thread. Testing a pattern against a long non-matching input, not just matching ones, is how you find this before it finds you.
Anchors, flags and word boundaries
Without anchors, a pattern matches anywhere in the string. A validation regex without `^` and `$` will happily accept an input that merely contains something valid — which is how an email validator ends up accepting an entire paragraph with an address buried in it.
Flags change the meaning substantially: global changes how many matches are found, multiline changes what the anchors mean, and case-insensitivity changes matching in ways that interact with Unicode. A pattern that works in a tester and fails in code is usually a flag difference.
When not to use a regex
HTML and other nested structures cannot be parsed by regular expressions, because nesting is not something a regular language can express. Patterns that appear to work do so on the specific examples tried and break on the first unusual case. Use a parser.
Email addresses are the other trap: the specification permits far more than people expect, and a strict pattern rejects valid addresses. Checking for an `@` with something either side and then sending a confirmation message is more reliable than any pattern. Testing runs entirely in your browser, so patterns and sample data — often production log lines — are not transmitted anywhere.