Regex Tester

Your pattern is compiled with the browser's native RegExp constructor, which means the results are not an approximation of what JavaScript does — they are what JavaScript does. If a pattern matches here it matches in your JS or TypeScript; if it throws here it throws there, with the same message.

That matters because regular expressions are not one language. PCRE, Python's re, Go's RE2, Java and JavaScript all differ, sometimes in ways that fail silently rather than loudly. Lookbehind, named groups, atomic groups, possessive quantifiers, recursion and the exact meaning of a dot all vary. A tester built on a different engine can happily tell you a pattern works when your runtime disagrees.

The global flag is always applied so you see every match rather than only the first, which is almost always what you want while building a pattern. The i, m and s flags are yours to toggle: i for case-insensitive, m to make ^ and $ match at line boundaries rather than only at the ends of the input, and s to let the dot match newlines as well.

Each match is listed with the index at which it starts and the contents of every capture group, in order. Groups are what turn a regex from a test into an extractor, and seeing them broken out is usually what tells you whether a pattern is doing the right thing.

A pattern can match while capturing the wrong thing, which is the failure mode that reaches production. Checking the group columns rather than just the highlight is the habit worth forming.

Highlighting is rendered from match positions rather than by injecting markup, so a pattern that matches something resembling HTML cannot alter the page. That is a deliberate choice: a regex tester that built its highlights by string substitution would be trivially self-XSS-able with the very patterns people test.

Language models write regular expressions well — genuinely better than most people, and faster. If you need a pattern for an email or an ISO date, asking is a reasonable way to get one.

What a chat window cannot do is show you the pattern running against your data, live, as you adjust it. Regex is an iterative craft: you write something, see what it over-matches, tighten it, see what it now misses. That loop is the work, and it needs your actual text — the messy log lines with the odd malformed entry, not a clean example.

And your actual text is usually the problem. The strings people test patterns against are production log lines, customer records, exported CSVs, API responses — data that carries names, email addresses, tokens and internal hostnames. Pasting a representative sample into a third-party service is a data transfer, whether it happens in a chat window or in a server-side regex tool, and it is one nobody records as such.

Running locally makes the question moot. Compile the pattern, run it against everything you have, iterate as much as you like, and none of it leaves the tab. Ask a model for the pattern if you want; bring it here to test it against the real thing.

Some patterns are slow in a way that scales terrifyingly. Nested quantifiers over overlapping character classes — the classic shape is a repeated group that itself contains a repetition, applied to a string that nearly but does not quite match — can force the engine to try an exponential number of paths. Patterns like this are fine on ten characters and hang the tab on forty.

This is not a curiosity. It is a denial-of-service class in its own right, and it is why you should be wary of running user-supplied patterns on a server, and why testing a pattern against realistically long input matters before shipping it. If the page becomes unresponsive while you type, that is the pattern telling you something.

Two smaller traps are worth naming. A dot does not match a newline unless you enable the s flag, which is the usual reason a multi-line extraction quietly returns nothing. And ^ and $ anchor to the whole string, not to each line, until you enable m — the second most common cause of a pattern that works on one line and fails on a file.

Finally, regular expressions cannot parse nested structures. HTML, JSON and balanced brackets are not regular languages, and any pattern that appears to handle them is handling the cases you tested and will fail on the ones you did not. Use a parser for structured data and keep regex for what it is good at: finding and extracting patterns in flat text.