About the Regex Tester
A regular expression that works on your three test strings and fails on real input is the normal outcome of writing one without testing it against the edge cases. This tester runs your pattern as you type, highlights every match, and shows the capture groups, so the thing you are guessing about becomes something you can see.
The most expensive regex bug is not a wrong match, it is a slow one. Patterns containing nested quantifiers over overlapping character classes can take exponential time on input that merely fails to match, and because the input is often user-controlled that turns a validation pattern into a denial-of-service vector. The classic shape to watch for is a repeated group that itself contains a repetition, such as one that repeats a group of one-or-more of some character class.
Matching runs entirely in your browser with the JavaScript engine, so patterns and test data never leave your machine.
Frequently asked questions
Why does my regex work here but not in my language?
Flavours differ more than people expect. This tester uses the JavaScript engine. PCRE, Python, Go, and POSIX differ in lookbehind support, named-group syntax, whether backslash-d matches non-ASCII digits, and how they treat unescaped braces. Go in particular uses RE2, which deliberately has no backreferences and no lookaround at all, so a pattern using either simply will not compile there.
What is catastrophic backtracking?
It is when a pattern with nested or overlapping quantifiers has to try an exponential number of ways to match before it can conclude that it does not match. A pattern like a repeated group of one-or-more of the same character, followed by a literal that is absent, can hang for seconds on a few dozen characters of input. If the input comes from a user, that is a denial-of-service bug, not a performance nit.
Greedy or lazy quantifiers — which should I use?
Greedy is the default and takes as much as it can, then gives characters back until the rest of the pattern fits. Lazy takes as little as possible and expands. The classic case is matching an HTML-like tag: a greedy dot-star will swallow everything up to the last closing bracket on the line, while a lazy one stops at the first. When you find yourself reaching for lazy matching, a negated character class is usually faster and less ambiguous than either.
Why does my anchor not match at the end of a line?
Without the multiline flag, the start and end anchors match only at the very beginning and end of the whole input. With multiline they also match at each line boundary. Separately, the end anchor in most flavours will also match immediately before a trailing newline, which is why a pattern can appear to accept a value that has a stray newline attached.
Should I validate email addresses with a regex?
Only loosely. The grammar for a genuinely valid address is far more permissive than people assume, and every short pattern that claims to implement it rejects real addresses. Check that there is exactly one at-sign with something on each side, then prove the address by sending mail to it. That is the only check that establishes what you actually care about.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.