The pattern you enter is compiled as a JavaScript regular expression and run against your test string, and every match is listed with a count. Flags are entered separately: g finds every match rather than stopping at the first, i ignores case, m makes the start and end anchors match at each line, and s lets a dot match a newline.
The regular expression engine here is the browser's, which is the same one your JavaScript will use. That is worth knowing because the syntax is not universal: patterns written for PHP, Python or a text editor may use features JavaScript lacks, and lookbehind in particular has a different support history. If the pattern will not compile, the engine's own message is shown rather than a generic failure.
Getting a pattern that holds up
-
Without the g flag you get one match:
the count stops at the first occurrence, which is the usual reason a working pattern seems to find far less than it should.
-
Test against text that should not match:
a pattern that matches what you want is only half of it. The mistakes that reach production are patterns matching more than intended.
-
Nested quantifiers can hang the page:
a pattern such as one repetition inside another can take exponential time on input that nearly matches. If a test seems to freeze, that is usually why.
-
Escape what you mean literally:
a dot matches any character until it is escaped, which is why patterns meant to match a filename or an address quietly match far more than expected.
Compiled by the same engine your JavaScript will use
A pattern entered into the [msm_tool slug="regex-tester"] is compiled as an actual JavaScript regular expression and run for real, using the browser's own engine — the same one any JavaScript on the page would use. That matters because regex syntax is not universal: a pattern written for PHP, Python or a text editor can rely on features JavaScript does not have, and lookbehind in particular has a genuinely uneven support history across engines.
Without the g flag, you get exactly one match
Leaving the global flag off stops the search at the very first occurrence, which is the ordinary reason a pattern that clearly looks correct appears to find far less than it should. Adding it is usually the entire fix for a match count that seems inexplicably low.
Nested quantifiers can hang the page
A pattern with one repetition nested inside another can take exponential time against input that almost matches but not quite, which is exactly the shape of input most likely to appear in practice. If a test seems to freeze rather than simply run slowly, this is almost always why — and the same pattern would cause the identical problem running in production, not just here.
A dot matches everything until it is told not to
An unescaped dot matches any character at all, which is why a pattern meant to match a filename or an email address quietly matches a great deal more than intended unless the dot is escaped where a literal period is actually meant. This is one of the most common gaps between what a pattern was meant to do and what it actually does.
Test against what should not match, not only what should
A pattern that correctly matches the intended input is only half the job done. The mistakes that make it into production are almost always patterns that match more than intended, which only shows up by deliberately testing against text the pattern is supposed to reject.
What it will not show you
Whole matches are listed along with a total count, but individual capture groups are not broken out separately here. Inspecting a pattern group by group means running it in actual code, where each group can be read directly rather than inferred from the whole match.