Regex performance & safety

Why some regexes get very slow

A regular expression, or regex, describes a shape of text, like "one or more letters". JavaScript checks a regex with a backtracking engine. The engine tries one way to match. If that way fails, it goes back and tries another way.

Most patterns leave only a few ways to try. Some patterns leave a huge number of ways. Then one short string can keep the engine busy for a very long time before it can say "no match".

This is the last lesson in the Regular expressions module. It uses ideas from the earlier lessons: patterns and flags, character classes, greedy and lazy quantifiers, groups and backreferences, and anchors and lookaround. You don't need to fear regex. You only need to know when a pattern is safe to run on text that users send.

The table below lists three questions to ask about any regex. Read each row as: "ask this, aim for this, and watch out for this."

In this lesson you will:

• step through a tiny matcher and count its tries,
• watch the count grow for two risky patterns,
• build a small tokenizer with the sticky flag,
• choose built-in tools instead of a regex: URL objects, JSON.parse, the DOM tree, and string methods.

Backtracking means going back to the last choice and trying a different one. A quantifier like + makes a choice: how many letters to take. A greedy quantifier first takes as many letters as it can. If a later part of the pattern then fails, the engine goes back. It makes the quantifier give one letter back, and it tries again.

The experiment below is a tiny matcher written in plain JavaScript. It handles only one pattern, (a+)+$, checked from the start of the text:

• a+ means one or more a letters. Call that a chunk.
• The round brackets and the outer + repeat the chunk one or more times.
• $ means "the text must end here".

The matcher counts every step it takes. At the end it checks that its answer, true or false, is the same as the real JavaScript regex answer.

1function matchNested(input) {2  let steps = 0;3  function repeatFrom(index) {4    steps++;5    if (index === input.length) return index > 0;6    if (input[index] !== "a") return false;7    let end = index;8    while (input[end] === "a") end++;9    for (let stop = end; stop > index; stop--) {10      if (repeatFrom(stop)) return true;11    }12    return false;13  }14  const matched = repeatFrom(0);15  return { matched, steps };16}17 18const input = "aaa!";Run19const result = matchNested(input);20console.log(result.matched);21console.log(result.steps);22console.log(/^(a+)+$/.test(input));

Look at the loop over stop on line 9. It decides how many letters the inner a+ takes. For "aaa!", it can cut the three letters into chunks in four ways:

• aaa as one chunk,
• aa, then a,
• a, then aa,
• a, a, and a.

Every way fails, because after the letters comes !, not the end of the text.

The next lab counts the steps for longer texts. It also counts a second risky pattern, (a|aa)+$, which means "one or more pieces, where each piece is a or aa".

1function matchNested(input) {2  let steps = 0;3  function repeatFrom(index) {4    steps++;5    if (index === input.length) return index > 0;6    if (input[index] !== "a") return false;7    let end = index;8    while (input[end] === "a") end++;9    for (let stop = end; stop > index; stop--) {10      if (repeatFrom(stop)) return true;11    }12    return false;13  }14  const matched = repeatFrom(0);15  return { matched, steps };16}17 18const input = "aaa!";19const result = matchNested(input);20console.log(result.matched);21console.log(result.steps);22console.log(/^(a+)+$/.test(input));

For (a+)+$, each extra letter doubles the count. The second pattern grows a little slower, but its count still climbs very fast.

When you check a regex for speed, first name its shape. A long pattern can be safe. A short pattern can be dangerous. The danger comes from ambiguity: the same letters can be matched in more than one way, and the number of ways grows with the text.

There are three shapes to look for:

• Nested quantifier: a repeat inside a repeat, like (a+)+.
• Overlapping choices: two choices that can match the same letters, like (a|aa)+.
• Side-by-side repeats: two repeats next to each other that both want the same letters, like a*a*.

1const examples = [2  "nested quantifier: ^(a+)+$",3  "overlapping choices: ^(a|aa)+$",4  "side-by-side repeats: ^a*a*$",5];6console.log(examples.length);7console.log(examples[0].includes("nested"));

The table below pairs each risky shape with a safer way to write it. Read each row as: "this shape is risky, so do this instead."

Anchors like ^ and $ only say where a match must start or end. They don't remove the choices inside the pattern. If the rule is simply "one or more a letters", remove the repeated group.

const input = "aaaa!";
console.log(/^(a+)+$/.test(input));
console.log(/^a+(?![\s\S])/.test(input));
console.log(/^a+(?![\s\S])/.test("aaaa"));
console.log(/^a+(?![\s\S])/.test("aaaa\n"));

Line by line:

1. Line 1 stores the text "aaaa!".
2. Line 2 prints false. Before it gives up, the nested group tries many ways to cut the letters into chunks.
3. Line 3 also prints false, with far fewer tries. There is only one repeat, so it tries at most one way per letter.
4. Line 4 prints true. The new pattern still accepts aaaa.
5. Line 5 prints false for aaaa with a line break at the end.

The end check (?![\s\S]) is a lookahead. It means "no character of any kind comes next", so it passes only at the very end of the text. Unlike $, it keeps working that way even if someone later adds the m flag. These lines check results only. They don't time the slow pattern.

Some other regex languages have tools that stop backtracking: possessive quantifiers, like a++, and atomic groups, like (?>...). JavaScript has neither. So in JavaScript, keep patterns safe in these ways:

• Use one clear character class instead of a repeat inside a repeat.
• Make sure two choices can't match the same letters.
• Check the whole text from start to end when you mean the whole text.
• Limit the length of the text before you match.

The panel below uses these rules to check a slug: the short lowercase name at the end of a web address, like regex-performance.

1function acceptsSlug(slug) {2  if (slug.length > 32) return false;3  return /^[a-z]+(?:-[a-z]+)*(?![\s\S])/.test(slug);4}5 6console.log(acceptsSlug("regex-performance"));7console.log(acceptsSlug("regex--performance"));8console.log(acceptsSlug("a".repeat(40)));9console.log(acceptsSlug("regex-performance\n"));

In the browser, JavaScript runs your code on one main thread: a single worker that does one job at a time. Node runs a server's code the same way, with an event loop that takes jobs one by one. A regex match is a job that keeps the computer busy. While it runs, nothing else runs: no clicks, no timers, no page updates, and no other server requests.

This has happened to large websites:

• Stack Overflow, July 2016. A post with about 20,000 space characters in a row made a regex that removes trailing spaces backtrack a huge amount. The site was down for 34 minutes. The report gave the simplified pattern as \s+$. Its work grew with the square of the length (quadratic), not by doubling (exponential). That was still enough to take the site down. Source: ADTmag’s summary of the StackStatus postmortem.
• Cloudflare, July 2019. Cloudflare added a new rule to its WAF (Web Application Firewall), a filter that blocks bad web traffic. The rule had a regex that pushed CPU use to 100% on the machines that serve web pages. Cloudflare was down worldwide for 27 minutes, from 13:42 to 14:09 UTC, and traffic dropped by 82% at the worst point. Source: Cloudflare’s postmortem.

You can stack several defenses. Read each row of the table as: "this defense gives you this, and this is how you use it."

For a short profile tag, check the length first and reject text that is too long. Don't cut the text down to size instead. Cutting could turn a bad tag into a different tag that passes.

function acceptsTag(tag) {
  if (tag.length > 12) return false;
  return /^[a-z]+(?![\s\S])/.test(tag);
}
console.log(acceptsTag("tea"));
console.log(acceptsTag("a".repeat(13)));
console.log(acceptsTag("tea!"));

Line by line:

1. Line 2 returns false for any tag longer than 12, before the regex runs.
2. Line 3 accepts only lowercase letters, all the way to the very end of the text.
3. Lines 5 to 7 print true, then false (13 letters is too long), then false (! is not a letter).

length counts JavaScript string units, not the characters you see, so this rule is meant for plain English letters only. A length limit keeps the work small, but it doesn't fix a risky pattern by itself.

In the browser, you can run an untrusted pattern in a Web Worker: a separate thread that runs beside the page. A timer can't stop a regex that is already running on the main thread. It can stop a worker, with terminate().

The code below is only the page's half. It also needs a separate file, regex-worker.js, that runs the match and sends back the result. So it won't run by itself in the lesson editor.

1const worker = new Worker("regex-worker.js");2const timeout = setTimeout(() => {3  worker.terminate();4  console.log("regex worker stopped");5}, 50);6 7worker.onmessage = (event) => {8  clearTimeout(timeout);9  console.log(event.data.matched);10};11 12worker.postMessage({ pattern: "^(a+)+$", input: "aaaa!" });

1. Line 1 starts the worker.
2. Lines 2 to 5 start a 50-millisecond timer. If the timer fires first, line 3 stops the worker and line 4 prints a note.
3. Lines 7 to 10 handle the worker's answer. Line 8 cancels the timer, and line 9 prints the result.
4. Line 12 sends the pattern and the text to the worker.

Tools can also catch risky patterns before your code runs:

• eslint-plugin-regexp finds regex mistakes and suggests clearer or faster patterns.
• safe-regex warns about many patterns that can get very slow. Its own docs say it can miss some risky patterns and can warn about safe ones.
• For Node servers, RE2 bindings use an engine that never backtracks, so its time grows only in step with the text length. It can't run backreferences or lookaround.
• V8, the engine inside Chrome and Node, has an experimental engine that doesn't backtrack. It turns on only with special flags, so don't count on it in ordinary JavaScript.

A regex with the g (global) flag or the y (sticky) flag remembers a position in a property called lastIndex. The next match starts from there. The two flags differ in one way:

• With g, the search starts at lastIndex and may move ahead to a later match.
• With y, the match must start exactly at lastIndex, or it fails.

Read each row of the table as: "in this situation, this is what g does, and this is what y does."

That exact position is just right for a tokenizer, also called a lexer. A tokenizer is code that cuts text into small pieces called tokens, like words, numbers, and signs.

The tokenizer below skips any spaces, then reads one name, one number, or one = sign. If the next character can't start a token, it stops right there with an error. It never jumps ahead and hides the problem.

1const token = /\s*([A-Za-z_]\w*|\d+|=)/y;Run2const input = "let count = 3";3const parts = [];4 5while (token.lastIndex < input.length) {6  const before = token.lastIndex;7  const match = token.exec(input);8  if (!match) throw new Error("stuck at " + before);9  parts.push(match[1]);10}11 12console.log(parts.join(" | "));13console.log(token.lastIndex);

The next panel runs the same search on "xxcat" with both flags. Both start at lastIndex 1.

1const text = "xxcat";2const global = /cat/g;3global.lastIndex = 1;4const foundGlobal = global.exec(text);5console.log(foundGlobal.index);6console.log(global.lastIndex);7 8const sticky = /cat/y;9sticky.lastIndex = 1;10console.log(sticky.exec(text));11console.log(sticky.lastIndex);

A regex with g or y keeps its lastIndex between calls. So if you use one regex for several separate form fields, the next field may start in the wrong place, even when it holds the same text.

const digit = /\d/y;
console.log(digit.test("3"));
digit.lastIndex = 0;
console.log(digit.test("3"));
console.log(digit.test("3"));

1. Line 1 makes a sticky regex that matches one digit.
2. Line 2 matches "3" and prints true. lastIndex is now 1.
3. Line 3 sets lastIndex back to 0 before the next field.
4. Line 4 prints true again.
5. Line 5 has no reset. It starts at index 1, finds no digit there, and prints false.

So the output is true, true, false. Reset lastIndex before each separate text, or use a regex without g or y.

A regex is good for simple text shapes: a slug, a short token, a known start, or one small piece of a line. It is the wrong first tool when JavaScript already has a parser for the format. A parser is code that reads a format by all of its rules.

Read each row of the table as: "for this job, a regex can go wrong like this, so use this instead."

1const doc = new DOMParser().parseFromString(2  "<article><h1>Regex</h1><p>Use a parser.</p></article>",3  "text/html",4);5console.log(doc.querySelector("h1")?.textContent);6console.log(doc.querySelector("p")?.textContent);

Line 1 asks DOMParser to read the HTML string and build a document from it. Lines 5 and 6 find the h1 and p elements and print their text: Regex and Use a parser.

1const page = new URL("/search?q=regex", "https://example.com");2console.log(page.searchParams.get("q"));3console.log(JSON.parse('{"safe":true}').safe);4console.log("lesson.regex.md".endsWith(".md"));5console.log(new Intl.DateTimeFormat("en-US", {6  month: "short",7  timeZone: "UTC",8}).format(new Date("2026-09-26T00:00:00Z")));

1. Lines 1 and 2: URL reads the address, and searchParams.get("q") prints regex.
2. Line 3: JSON.parse reads the JSON and prints true.
3. Line 4: endsWith checks the end of the file name and prints true.
4. Lines 5 to 8: Intl.DateTimeFormat prints the short month name, Sep.

For a simple check on a message, string methods say what you mean with no regex at all. They compare letters exactly, so uppercase and lowercase count as different letters.

const message = "Order ready: tea";
console.log(message.startsWith("Order ready:"));
console.log(message.includes("tea"));
console.log(message.includes("Tea"));

1. Line 2 prints true: the message starts with Order ready:.
2. Line 3 prints true: the message contains tea.
3. Line 4 prints false: uppercase T is not the same letter as lowercase t.

If a search should ignore uppercase and lowercase, change both strings to lowercase first, for example with toLowerCase().

If you check many values with the same regex, make the regex once, outside the loop. Leave off g and y, so each value is checked from the start.

const tagPattern = /^[a-z]+(?![\s\S])/;
for (const tag of ["tea", "tea!"]) {
  console.log(tagPattern.test(tag));
}

Line 1 makes the whole-tag check once. Line 2 loops over two tags. Line 3 prints true for tea and false for tea!. No lastIndex carries over between the calls. Making the regex once saves building it again for every item, but it doesn't make a risky pattern safe.

Be extra careful with email. A giant "perfect email regex" is hard to read and still gets real addresses wrong. For most sites, keep the check in the browser simple. Then send an email to prove the address works.

Dates are similar. Use Temporal for date math where it exists, and Intl to show dates. Don't try to fit calendars and time zones into a pattern.

Common misconceptions

• "Lazy quantifiers are safe." Lazy quantifiers, like +?, still backtrack. They just try the shortest choice first.
• "Anchors fix slow patterns." Anchors limit where a match can start or end. They don't remove the extra choices inside the pattern.
• "If it's fast on my test strings, it's safe." Risky patterns often look fine on normal text. Then someone sends text that fails near the end, adds a few more letters, and the time explodes.
• "A tool said my regex is safe, so it is." Linters and scanners give useful warnings. But they can miss a risky pattern or warn about a safe one. Treat them as one layer of defense.
• "A regex is always faster than string methods." To check "contains", "starts with", or "ends with", or to split text, string methods are clearer. Which one is faster depends on the text and the engine, so measure only when speed really matters.

Read each row of the table as: "people believe this, so do this instead, for this reason."

Key takeaways

• A backtracking engine can try many equal ways to match before it finally fails.
• Watch for three risky shapes: nested quantifiers, overlapping choices, and side-by-side repeats.
• ReDoS blocks real work, because a regex match keeps the browser's main thread or Node's event loop busy.
• The sticky y flag makes lastIndex the exact place where the next token must start. A failed match with g or y sets it back to 0.
• Use parsers and built-in tools for HTML, URLs, JSON, dates, email checks, and simple text checks.

That ends the Regular expressions module. Next comes typed arrays, the first lesson in Binary data & memory. It moves from text patterns to bytes, buffers, and views into memory.