Regex cookbook and tester

A bad regex is a production outage, not a typo

It is easy to treat a regular expression as a small, contained thing — a pattern you write once, glance at, and ship. The clearest counterexample on record is a postmortem Cloudflare published about its own network, and it is worth reading in full rather than taking secondhand.

On 2 July 2019, a single rule deployed to Cloudflare’s Web Application Firewall contained a regular expression with the classic catastrophic-backtracking shape — a repeated group whose own contents could also repeat, so the engine tried an exponential number of ways to fail a match before giving up. Because a WAF rule runs against every request passing through, that one pattern drove CPU usage toward 100% across Cloudflare’s global network almost immediately. With core proxy, CDN and WAF capacity pegged, the network served 502 errors to a large share of its traffic for roughly 27 minutes before the rule was pulled.

Two contributing factors turned a bad pattern into a global incident rather than a contained one. The rule went out everywhere in one step, with no staged or canary rollout that would have surfaced the CPU spike on a slice of traffic before it reached all of it. And a CPU-usage safeguard that had once existed specifically to catch a runaway regular expression before it consumed a whole core had been removed in an earlier, unrelated refactor. Either mitigation alone — the staged rollout, or the reinstated CPU guard — would likely have kept the incident local. The regex engine involved matched by backtracking with no runtime guarantee against this class of input, which is not a defect unique to that one engine: most regex engines in everyday use, including PCRE, Python’s re and JavaScript’s own RegExp, share the same backtracking design and the same exposure.

This is the general class of bug called ReDoS — regular expression denial of service — and OWASP’s page on it is a good next stop. The vulnerability is not a mistake in one pattern’s logic so much as a structural property some patterns have: ordinary test input never exercises it, and adversarial — or simply unlucky — input can trigger it by accident. That is exactly why this page runs every match inside a Web Worker with a hard deadline it can terminate, rather than directly on the page’s main thread; see how that timeout actually works above.

A pattern that looks fine against the three test strings you tried by hand can still be the one that hangs on the fourth. Testing a pattern against realistic — and deliberately adversarial — input before it ships is the cheap step that catches this, and it is what the tester on this page is for.

Read the reporting yourself

• Cloudflare — “Details of the Cloudflare outage on July 2, 2019” The company’s own published postmortem: root cause, timeline, and the fixes that followed.
• OWASP — Regular expression Denial of Service (ReDoS) The general vulnerability class: what makes a pattern susceptible, and how to recognise the shape.

Copy-paste pattern library

Nine ready patterns for the problems that come up again and again. Every one targets JavaScript’s own regex flavour — see flavour honesty below for exactly where that differs from PCRE or Python. Click Try it to load a pattern straight into the tester above with its own worked example, or Copy to take just the pattern.

Flavour honesty: this is JavaScript’s regex, not PCRE or Python’s

Every pattern on this page runs through JavaScript’s built-in RegExp. That flavour is close to, but not identical with, the PCRE engine behind PHP and most command-line grep-style tools, or Python’s re module. Copying a pattern between them without adjustment is a common source of “this worked everywhere except my browser” bugs. Specifically:

• Named groups. JavaScript spells a named capturing group (?<name>…). Python spells the same thing (?P<name>…). Pasting Python’s form into a JavaScript RegExp throws a SyntaxError — this page will show you that error rather than silently failing.
• Lookbehind. (?<=…) and (?<!…) are supported in current Chrome, Firefox and Edge, and in Safari from version 16.4 (March 2023). A pattern using lookbehind will throw in older Safari and in some embedded JS engines. PCRE and Python have supported lookbehind for much longer, so a pattern working in a Python script may still fail in an old browser.
• No possessive quantifiers, no atomic groups. PCRE offers a++ (possessive) and (?>…) (atomic) specifically to cut off backtracking early, which is also a standard defence against catastrophic backtracking. JavaScript has neither. That is one reason a pattern that is safe in PCRE can still be dangerous here — see the ReDoS section below.
• No recursion. PCRE supports recursive patterns ((?R)) for matching nested structures such as balanced parentheses. JavaScript regex cannot recurse at all; balanced-nesting problems need a real parser, not a pattern.
• \d, \w and Unicode. Without the u flag, JavaScript’s shorthand classes are ASCII-only, same as PCRE’s default. With u, JavaScript still does not expand \d to every Unicode decimal digit — for that you need the explicit Unicode property escape \p{Nd}, which requires the u (or v) flag and is not available in every engine that claims Unicode support.

None of this makes JavaScript’s regex worse — it is simply a different implementation of a specification (ECMA-262) that overlaps heavily with, but is not identical to, PCRE or Python’s re. The patterns in the library above are written to work as JavaScript regex specifically, and the tester on this page only ever compiles and runs JavaScript regex — if you paste a PCRE- or Python-only construct, you will see the SyntaxError immediately rather than a confusing runtime difference later.

How it works

Compiling a pattern

Every pattern you type is handed to new RegExp(pattern, flags), wrapped in a try/catch. Constructing a RegExp from bad syntax — an unmatched [, a dangling (, a quantifier with nothing before it — throws a SyntaxError, and without the wrapper that exception would be unhandled and the page would break. Here it becomes the message you see under the pattern field instead: the engine’s own words for what is wrong, immediately, with no separate “validate” step required.

Stopping a runaway pattern from freezing the tab

A hand-written regex tester has one failure mode that matters more than any other: catastrophic backtracking. The textbook example is /(a+)+$/ against a string of many as followed by a character that can never match, such as aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!. The inner + and the outer + both repeat, so the engine tries an exponential number of ways to divide the same run of as between them before it can conclude there is no match. On a string of thirty characters that is already billions of attempts; add a few more characters and it stops being something you wait out.

This page defends against that in three layers, and it is worth being precise about what each one actually does, because two of the obvious-sounding defences do not really work:

• A heuristic warning, before running anything. The pattern text is scanned for the textbook shape — a group that can itself repeat, wrapped in another repetition, like (a+)+ or ([a-z]*)*. If it matches, you see a warning badge before the tester runs the pattern at all. This is advisory only: it will miss some genuinely catastrophic patterns (the danger can hide behind alternation or backreferences a simple text scan cannot see) and could in principle flag a rare safe one, so it is a hint, never a block.
• A capped iteration count — but this is not the real fix. The match loop stops after 20,000 iterations and reports that it was truncated. It is tempting to assume this is what prevents a freeze, but it is not: catastrophic backtracking happens inside a single call to the engine’s match function, before that call ever returns to the loop that is counting iterations. Capping the number of loop iterations only helps a different, unrelated problem — a pattern that matches validly but produces an enormous or endless number of matches (for instance, a pattern that can match a zero-length string, repeated across a very long input).
• The actual fix: a Web Worker with a timeout. Matching does not run on the same thread as the page you are looking at. It runs inside a same-origin Web Worker — a background script this page starts, loaded from a file next to this one, not a network request. The tester starts a timer the moment it sends a pattern to the worker. If the worker has not replied by the deadline, the page calls Worker#terminate(), which kills the worker outright — even though it is still stuck deep inside a native RegExp#exec call that will never return on its own — and a fresh worker is created for your next attempt. Terminating a worker does not touch the main thread at all, which is precisely why the rest of the page keeps responding to clicks and typing throughout. That is the property that actually matters: not that the runaway match finishes quickly (it may never finish), but that killing it is always possible and never blocks anything else.

There is a smaller, easier-to-fix trap in the same neighbourhood: a pattern that can match a zero-length string with the global flag on, such as /x*/g against text with no x in it. A naive loop that calls exec() and only relies on the engine to advance its own position can match the same empty string at the same index forever. This page’s matching loop checks the length of every match and manually advances lastIndex by one whenever a match is zero-length, which is the standard, documented way to make that loop terminate.

Explaining a pattern in plain English

The explainer is a second, completely separate pass over the pattern’s text — it never compiles or runs the pattern, so it carries none of the risk described above, no matter how pathological the pattern looks. It walks the pattern character by character, recognising anchors, character classes and their shorthand forms, groups (capturing, non-capturing, named, lookahead, lookbehind), backreferences, and the four quantifier shapes with their greedy and lazy variants, and produces one row per token: the raw text on the left, a sentence on the right. It is a hand-written scanner rather than a full parser, so a handful of exotic constructs get a generic description instead of a precise one — an accepted trade-off for explaining the common 95% of patterns clearly, which is what a cookbook is for.

Substitution

The replace tab supports the same template syntax JavaScript’s own String.prototype.replace understands: $& for the whole match, $1–$99 for numbered groups, $<name> for named groups, and $$ for a literal dollar sign. It is reimplemented here rather than calling .replace() directly so that substitution goes through the exact same capped, manually-advanced matching loop as the Matches tab — one ReDoS story for both features, not two, and both run inside the same worker with the same timeout.

Never an unhandled error, never raw HTML from your input

Two more things worth stating plainly. First: every operation on this page — compiling, matching, explaining, substituting — is wrapped so that a bad pattern or bad input produces a message, never a crash. Try [, ( or a bare * in the pattern field and you get the engine’s own explanation, not a blank page. Second: every value that reaches the screen from your pattern or your test text — the highlighted matches, the match list, the explanation, the substitution result — is written with textContent, never assembled into an HTML string. Paste <img src=x onerror=alert(1)> as test text and it renders as those literal characters, because there is no code path on this page that turns your text into markup.

Worked examples

^(?<date>\d{4}-\d{2}-\d{2}) (?<time>\d{2}:\d{2}:\d{2}) (?<level>[A-Z]+) (?<service>[\w-]+):

Reference: tokens, quantifiers, anchors, classes and flags

Character classes

Quantifiers

Anchors and boundaries

Groups and lookaround

Flags

Frequently asked questions

Use cases and limitations

What people use this for

• Validating form input — email shape, phone shape, a slug for a URL — before it reaches a server, as a first-line typo catcher, not a proof of correctness.
• Pulling fields out of semi-structured text — log lines, CSV-ish exports, config values — using named groups to get a small object back instead of a yes/no match.
• Bulk find-and-replace across text that follows a pattern but is not identical, such as normalising date formats or redacting anything that looks like a phone number, using the Replace tab’s $1/$&/$<name> template.
• Learning what an unfamiliar pattern does — paste a regex you found in someone else’s code into the Explain tab before you trust it in production.
• Checking a pattern is safe before shipping it — the catastrophic-backtracking warning catches the textbook danger shapes before a pattern goes anywhere near a server that might not have this page’s worker-timeout protection.

What it deliberately does not do

• Test PCRE, Python, .NET or any other flavour. One engine, the one already in your browser. See flavour honesty.
• Guarantee a pattern is ReDoS-free. The heuristic warning catches the textbook shape, not every possible catastrophic construct — the worker timeout is what actually protects the tab, on every pattern, whether or not the heuristic recognised it in advance.
• Parse HTML, JSON or any nested, recursive structure. Regex has no general answer to balanced nesting; that needs a real parser. Worked example 2 above walks through exactly this trap.
• Prove an email, phone number or URL is real. Syntax only — a validator that also confirmed deliverability or reachability would need to make an actual network request, which is out of scope for a page that runs entirely client-side.
• Find overlapping matches. Neither does JavaScript’s engine; see the FAQ above.

Honest limitations

The catastrophic-backtracking heuristic is advisory and incomplete by design — it recognises one well-known shape and will miss others, particularly ones hidden behind alternation or backreferences. The worker timeout is the real safety net and does not depend on the heuristic recognising anything. The plain-English explainer is a hand-written scanner, not a complete formal grammar for every legal JavaScript regex construct; it covers the constructs in the reference tables precisely and falls back to a generic description for the rest. Very large test strings (above roughly 200,000 characters) may be slow to highlight in full even when the pattern itself is safe, simply because building a match list and a highlighted view over that much text takes real work; the iteration cap keeps this bounded rather than unbounded, at the cost of a truncation notice on genuinely enormous inputs.

More tools on this site

• JSON formatterFormat, validate and explore JSON, entirely in your browser
• Cron expression generatorBuild and read cron schedules with a plain-English explanation
• Epoch & timestamp converterUnix time to and from a readable date, in any timezone

See all the tools on this site →