The flags that change everything
g finds every match rather than stopping at the first. i ignores case. m makes ^ and $ match at every line break instead of only at the start and end of the whole string — which is the flag people forget when a pattern works on one line and fails on many.
s lets . match a newline. Without it, a pattern trying to span two lines silently matches nothing.
Greedy by default
.* takes as much as it can and then gives back only what it must. Matching <.*> against <a>text</a> captures the entire string, not the first tag. Adding a question mark — .*? — makes it lazy and stops at the first possibility.
That single character is behind most "why is my regex matching too much" questions.
This is the JavaScript flavour
Patterns are run through your browser’s own engine, so what you see here is exactly what your JavaScript will do. That also means the syntax is JavaScript’s: no lookbehind in very old browsers, no possessive quantifiers, no recursion. PCRE, Python and Go each differ in small ways, so a pattern verified here is verified for JavaScript specifically.
One warning worth taking seriously: nested quantifiers such as (a+)+ against a long non-matching string can take exponential time. If a pattern hangs the tab, that is why — and the same pattern on a server is a denial of service waiting to happen.
Frequently asked questions
Why does my pattern match too much?
Quantifiers are greedy by default. Change .* to .*? to make it stop at the first possibility rather than the last.
Why does ^ not match my second line?
Without the m flag, ^ and $ mean the start and end of the whole string. Add m and they match at every line break.
Which flavour of regex is this?
JavaScript, using your browser’s own engine — so the result matches what your code will do. PCRE, Python and Go differ in details; verify there if that is where the pattern will run.
My browser froze on a pattern. What happened?
Catastrophic backtracking, usually from nested quantifiers like (a+)+ on a long non-matching input. Time grows exponentially. The same pattern on a server is a denial-of-service risk.
Something wrong with this tool, or an idea for it? Tell us