Which regex engine you are testing against
This uses the JavaScript regular expression engine built into your browser, not a server-side reimplementation. That is the point: if you are writing a pattern for JavaScript or TypeScript, what you see here is exactly what your code will do, including the engine own error messages when a pattern fails to compile.
It also means the syntax is JavaScript syntax. Lookbehind is supported in modern browsers, named capture groups work, and unicode property escapes work with the unicode flag set. What you do not get are the PCRE extensions people sometimes assume are universal: no recursion, no atomic groups, no possessive quantifiers, no inline comment syntax.
If your pattern is destined for Python, PHP, Go, or a database, treat this as a close relative rather than an authority. Character class shorthands and anchors mostly agree across engines; the edges around lookaround, unicode handling, and multiline semantics do not.
- The browser own JavaScript engine, so results match your JS code exactly
- Named groups and lookbehind work; PCRE-only features do not
- For other languages, verify the edges rather than assuming portability
Reading the output
The test string is re-rendered with every match wrapped in a highlight, which is usually the fastest way to see that a pattern is matching more or less than you intended. Above it, the panel reports how many matches were found in total.
Below that, each match gets its own card showing the matched text along with its start and end offsets in the string. Those offsets matter more than people expect: they are how you spot a pattern that is matching the right text in the wrong place, and how you catch an off-by-one in a group boundary. Zero-length matches are labeled explicitly rather than appearing as blank cards.
Capture groups are listed underneath each match, numbered in order, with groups that did not participate shown as undefined rather than silently omitted. Named groups appear separately by name. Seeing an unexpected undefined in the list is often the fastest route to understanding why an alternation is not doing what you thought.
Flags, quick patterns, and the one real hazard
Six flags are available as checkboxes, with global on by default. Global finds every match rather than only the first, ignore case does what it says, multiline makes the anchors match at line boundaries rather than only at the string boundaries, dotAll lets the dot match newlines, unicode enables proper handling of astral characters and property escapes, and sticky anchors each match to where the previous one ended. The newer indices and unicode-sets flags are not exposed.
The eight quick patterns replace the pattern field with a workable starting point for email addresses, URLs, digit runs, words, IPv4 addresses, hex colors, ISO dates, and whitespace runs. They are deliberately practical rather than exhaustive: the email pattern in particular is the pragmatic kind that matches what people actually type, not the specification-complete monster that matches every address the standard permits.
One hazard deserves stating plainly. There is no protection against catastrophic backtracking. A pathological pattern such as nested quantifiers over an alternation can take exponential time on the wrong input, and because the matching runs on the same thread as the page, a pattern like that will freeze the tab until it finishes or the browser gives up. That is a real property of the engine rather than a bug here, but it means you should be careful about what you paste when the test string is long.
- Global is on by default; the indices and unicode-sets flags are not exposed
- Quick patterns are practical starting points, not exhaustive validators
- No backtracking guard: a pathological pattern can freeze the tab