Regex Tester

What it does

Edit a pattern and a test string side by side and see every match highlighted as you type. Below the panes, a table lists each match with its index, the full match, and every capture group — numbered and named, with undefined printed literally so an optional group that never participated is distinguishable from one that matched an empty string. A replace view previews substitutions using the real $1, $<name>, $&, and $$ syntax, and a cheatsheet tab holds the syntax reference plus a handful of loadable starting patterns.

How it works

The engine is your browser’s own, so what you see is ECMAScript RegExp behavior as specified in ECMA-262 — not an approximation of it. All six flags are exposed: g, i, m, s, u, y. If g is off, exactly one match is reported, because that is what exec() does; the tool tells you to add the flag rather than quietly doing it for you.

Matching iterates with exec() and resets lastIndex first, which sidesteps the most common real-world bug with global regexes: a shared regex object carries its lastIndex between calls, so a module-level const re = /x/g used with test() appears to alternate between true and false on identical input.

Substitution is implemented directly rather than delegated to replace(), so the preview can be built from the same capped match list shown in the table. It follows the replacement patterns documented for String.prototype.replace.

Why the tool refuses to run some patterns

Backtracking engines can take exponential time on patterns where a quantifier wraps something that is already quantified. The canonical example is (a+)+b: against a string of 30 as with no b, the engine explores every partition of the run before concluding it cannot match, which takes about a minute of solid CPU. That is regular expression denial of service, and it has taken down production services that let users supply patterns — or merely supply input to a badly written one.

The important and often-glossed-over detail is that a single exec() call cannot be interrupted. JavaScript regex matching is synchronous and has no yield point, so an “iteration cap” is not, by itself, protection. What is here instead is layered and deliberately conservative: the pattern is screened for the two classic exponential shapes and is not executed until you tick “run it anyway”, the test string is capped at 20,000 characters, the match loop stops at 2,000 matches, and the loop abandons after a 250 ms budget. The screen is a heuristic. It will produce false positives on patterns that are fine in practice, and it will miss shapes it does not know about.

If you take one thing from this: server-side, a user-supplied pattern is user-supplied code. Run it in something you can kill, or use an engine with linear-time guarantees. Go’s regexp package uses RE2 and refuses backreferences and lookaround precisely so it can promise that.

When to reach for it

Working out why a log-parsing pattern misses the last line — usually a missing m flag, or $ anchoring to the end of input rather than the end of a line. Checking what a capture group actually contains before you index into it in code. Building a search-and-replace before running it across a repo, where getting $1 wrong the first time means a dirty diff. Confirming that \d is still just [0-9] and that the Unicode digits in that pasted CSV need \p{Nd} and the u flag. And demonstrating to someone that a pattern is dangerous without taking their browser down to prove it.

Related tools

• JSON formatter for the payload you are about to scrape with a pattern (parse it properly instead, where you can).
• URL encoder/decoder for query strings that need decoding before a pattern will match them.
• Markdown preview when the bulk edit is over a directory of .md files.
• Hash generator for checking a match against a known digest.
• Timestamp converter for the ISO 8601 strings your pattern just pulled out of a log line.