Regex Tester

Regular expressions are the smallest, most-used DSL in computing. Search-replace dialogs, log filters, web framework routers, validation rules, syntax highlighters, and every "extract phone numbers from text" task on the planet uses them. They are also famously hard to debug: a missing backslash silently changes meaning, a greedy quantifier eats more than you wanted, and a small mistake in a lookbehind makes the pattern silently match the wrong thing. The fix is not memorizing the syntax — it is testing patterns interactively against the exact input you care about, so you see at a glance what matches and what does not.

The tester uses the **ECMAScript regex engine** built into your browser. That is the same engine that runs in Chrome, Firefox, Safari, Node.js, Bun, and Deno, so a pattern you tune here will behave identically in your application code. Most of the standard regex features are supported: character classes, quantifiers, anchors, alternation, capturing and non-capturing groups, backreferences (`\1`, `\2`), lookaheads (`(?=…)`), lookbehinds (`(?<=…)`), named captures (`(?<name>…)`), and Unicode property escapes (`\p{L}`, `\p{Script=Hangul}`) when the `u` flag is enabled. Features that exist only in PCRE — recursive patterns, possessive quantifiers, the `\K` reset, conditional patterns — do not work because JavaScript itself does not implement them.

Flags matter more than people remember. `g` makes the regex global, scanning past the first match; without it, `String.prototype.match` returns only the first occurrence and `replace` only swaps the first instance. `i` is case-insensitive. `m` makes `^` and `$` match line boundaries rather than the start and end of the whole string — important whenever you are parsing input with newlines. `s` ("dotall") lets `.` match newlines, which is useful for matching across blocks of text. `u` switches the engine into Unicode mode, which both fixes surrogate-pair handling for emoji and astral characters AND unlocks property escapes like `\p{L}` for "any letter in any script." `y` ("sticky") forces matching from `lastIndex` only, which most application code never needs but tokenizers and parsers rely on.

The match list below the highlight view shows three pieces of information per match: the literal string that matched, the zero-based starting index, and every capture group's content. **Numbered groups** (`(\w+)` is `$1`) and **named groups** (`(?<name>\w+)` is `m.groups.name`) are listed separately even though they refer to the same content — because real-world code reads them via different APIs and seeing both lets you confirm your extraction logic. Undefined groups (a group that exists in the pattern but did not participate in the match, common with alternation like `(foo)|(bar)`) are explicitly shown rather than silently omitted.

Three practical hazards the tester surfaces. **Zero-width matches** — patterns like `/(?=\d)/g` that match a position rather than characters — naively loop forever in JavaScript. The tester advances one character past every zero-width match, matching how Chrome's DevTools, Node's REPL, and TC39's spec algorithm handle it. **Match explosion** — a pattern like `/./g` against a megabyte of text would render millions of `<mark>` elements and freeze the page; the tester caps at 5,000 matches and reports it. **Invalid patterns** — syntax errors come straight from the browser's `new RegExp()` constructor, so the error message is exactly what you would see in DevTools when the pattern reaches production.

Everything runs in your browser. The pattern is compiled by the browser's regex engine. No network requests, no logging. Patterns containing sensitive data (internal hostnames, employee emails, API keys you are validating) never leave your tab.