.*Regex Tester

The way most people write a regular expression is to reach for something close from an old project and adjust it until the test case passes. That is also why so many patterns match more than intended in production.

A better order: write the simplest pattern that matches one example, then feed it the cases that should not match. Negative testing is where patterns actually get fixed. Anything can be made to match; the skill is in what it excludes.

The flags

Without g the engine stops at the first match, which accounts for most of the why does it only find one confusion. i ignores case. m makes the anchors match at each line rather than only at the start and end of the whole string — relevant the moment you are working with pasted text rather than a single value.

Two failure modes worth recognising

An unescaped dot matches almost any character. A pattern like www.example.com will happily match wwwXexampleYcom, which is fine until it is not.

And catastrophic backtracking: nested quantifiers over overlapping characters make the engine try an exponential number of paths. If a pattern hangs the page on a long input rather than returning nothing, that is what happened. It is also a denial-of-service vector if the pattern runs on user input server-side.

On validating email addresses

Do it loosely. A pattern that implements the specification properly is enormous, and it still cannot tell you whether the address exists or whether anyone reads it. Check for an at sign with something either side, then send a confirmation email — which is the only validation that actually proves anything.

Portability

This runs the JavaScript engine. Most syntax is shared, but lookbehind support varies between languages, named group syntax differs, and a pattern that works here can behave differently in PHP or Python despite looking identical. Test in the runtime you are shipping to.