Regex Tester

Why a regex tester needs a worker

Most of the machinery on this page exists for one failure mode. Consider /(a+)+b/ matched against thirty as and no b. The engine has to decide how to split those thirty characters between the inner and outer quantifier, and there are 2³⁰ ways to do it. Every one is tried before the match can be declared impossible.

The important part is that a running regex cannot be interrupted. JavaScript is single-threaded, so a setTimeout guard cannot fire until the regex returns — which for that input is somewhere past the heat death of the universe. The tab is gone.

So the pattern runs in a Web Worker, on its own thread, and the main page holds a timer. When the timer wins, worker.terminate() kills the thread outright. That is the only mechanism that actually works, and it is why this tester tells you your pattern is dangerous instead of becoming a hung tab.

Worth internalising, because the same pattern in production code is a denial-of-service: user-supplied input matched against a vulnerable regex, and one request pins a CPU core indefinitely. The class of bug is called ReDoS.

The shapes to avoid

The common factor is ambiguity: more than one way for the pattern to consume the same characters. A character class does the job of an alternation without the ambiguity, which is why the safer column is mostly just replacing | with [].

Greedy, lazy, and the bug everyone writes once

Quantifiers are greedy by default: .+ takes everything it can and hands characters back only under protest. Against <b>bold</b>:

The third form is the one to reach for. A negated character class cannot overshoot, so there is no backtracking to undo — it is both clearer about intent and cheaper to run than the lazy version.

lastIndex, and why every other match disappears

A RegExp with the g flag is stateful. It keeps a lastIndex that advances after each exec or test, so reusing one object across separate calls resumes from wherever it stopped:

const re = /\d+/g;
re.test('123');  // true,  lastIndex is now 3
re.test('123');  // false! it resumed from index 3

Create the regex inside the loop, reset lastIndex = 0, or use matchAll, which manages it for you. The tester above creates a fresh object for every run, so what you see here is the first-call behaviour.

Where JavaScript regex differs

Results here match Node and browser code exactly, because it is the same engine. Against other languages, the differences that catch people out:

• No atomic groups or possessive quantifiers. PCRE has (?>...) and a++ to prevent backtracking outright; JavaScript has neither, which is why ReDoS is easier to write here.
• No recursion. You cannot match balanced brackets in JavaScript regex. If that is the requirement, you need a parser.
• Lookbehind arrived late. (?<=...) is supported in current browsers but not in older Safari, so check your targets.
• Go’s RE2 is a different machine. Linear time guaranteed, no backreferences, no lookaround. If you have ever wondered why Go dropped features, this page is the reason.

Related

If the text you are matching against is JSON, formatting it first usually makes the pattern unnecessary — a parser beats a regex on structured data every time. For scheduling rather than matching, the cron parser is the neighbouring tool.