Regex Tester — Online JavaScript Regular Expression Tester _

How does regex work in your browser?

Every JavaScript runtime ships a native regular expression engine — new RegExp(pattern, flags) compiles your pattern, then methods like String.prototype.match, String.prototype.replace, and RegExp.prototype.exec drive it against any input string. This tester wraps that engine in a UI so you can edit, run, and inspect patterns without leaving your browser. Nothing you type — pattern, flags, test string, or replacement — is sent over the network.

How does the regex tester work?

The pipeline is a few short steps, all of which run client-side on every keystroke (debounced to 150 ms so typing stays fluid):

1. Your pattern body is read from the input above (no leading or trailing / delimiters — they are decorative). The selected flag pills are concatenated into a flags string such as gi or gimsuy.
2. new RegExp(patternBody, flags) compiles the pattern. If the engine throws a SyntaxError (e.g. an unmatched parenthesis or an invalid escape), the message is rendered above the test string and the match list is cleared. The compile error is the actual err.message from V8 / SpiderMonkey / JavaScriptCore so it matches whatever you would see in DevTools.
3. For the match list, the tester always enumerates with a synthetic global flag — so even if you turn g off, the list still shows every match. The standard zero-width-match guard (if (m.index === rx.lastIndex) rx.lastIndex++) keeps the loop from spinning on patterns that match an empty string. The Replace mode honours your real flag set so $& behaves the same as String.prototype.replace.
4. Between every iteration the tester checks performance.now() - start and aborts once 50 ms have elapsed. This guards against catastrophic backtracking on inputs like (a+)+$ against a long run of a — the tab would otherwise hang. The guard is best-effort: a pathological single-match pattern can still consume time inside one exec call. If that ever happens, refresh the tab and rewrite the pattern with a non-greedy quantifier or an atomic-style possessive (e.g. [^x]*x).
5. The test string is split into segments at each match's range and the matched segments are wrapped in <mark class="rx-match rx-cap-N"> elements, where N cycles through six palette colours so adjacent matches are easy to tell apart at a glance. Each match's numbered groups (m[1], m[2], …) and named groups (m.groups) are rendered as labelled rows underneath; if the d flag is set, per-group [start, end] indices are shown too.

Why use this regex tester?

• Privacy: every pattern, test string, and replacement runs in your browser using the built-in JavaScript RegExp engine. Nothing leaves the tab — important when the input is a customer log, a leaked credential pattern, or anything else you would not paste into a hosted SaaS regex playground.
• Honest flavor: the tester exposes the exact regex engine that Node.js, Chrome, Safari, Firefox, and every browser-based form validator runs. There is no Perl-flavor translation layer to hide subtle differences — what works here works in your code.
• Capture and named-group debugging: every numbered group ($1, $2, …) and named group ($<year>) is shown per match so you can build a parser and read the slots back without guessing. The Replace mode lets you mix groups freely — $2-$1 swaps the first two slots, $<name> drops a named slot in, and $& echoes the whole match.
• Catastrophic-backtracking guard: a 50 ms ceiling on enumeration aborts pathological patterns like (a+)+$ before they freeze the tab. You see an explanatory error instead of a hung browser, and the page recovers immediately.

What are common applications of a regex tester?

Regular expressions show up across web development, security, and data work — this tester targets the most common use cases:

• Form validation: prototype an email, phone, or postal-code pattern, paste sample inputs into the test string, and confirm every positive case matches and every negative case does not before you ship the pattern to production code.
• Log scraping: paste a chunk of NGINX, application, or audit-log output, write a pattern with named groups for the parts you care about ((?<ip>…) (?<path>…)), and read the captured slots per match to confirm your parser is correct.
• Refactor search-and-replace: use Replace mode to rewrite identifiers across a snippet — (\w+)\.set(\w+)\( → $1.$2 = turns getter calls into property assignments, and the live preview shows the result before you commit it to a codemod.

What does a regex example look like?

Take the pattern (\d{4})-(\d{2})-(\d{2}) with the g flag, run against the test string release 2025-11-15, prerelease 2026-05-25. The engine finds two matches. The first match is 2025-11-15 with group 1 = 2025, group 2 = 11, group 3 = 15. The second match is 2026-05-25 with the same group shape. In Replace mode, the replacement template $3/$2/$1 rewrites both dates to 15/11/2025 and 25/05/2026 — a one-pattern ISO-to-DMY conversion you can verify visually before plugging the pattern into a script.

Use this tester as the fast path for any regex work — building, debugging, or rewriting patterns. Everything runs locally; nothing is logged; the regex engine is whatever your browser ships, so behaviour matches what production code will see at runtime.