Regex Libraries in 2026: Safety Tooling Grew Faster Than Syntax Sugar

Regular expression libraries are usually compared on syntax features. The install record is asking a different question, and the answer on this page is not close: what people install most is not a better way to write a regex, it is a way to find out whether someone else's regex will take their service down.

Source: the npm downloads API, window 2024-10-01 to 2026-10-10, pulled 2026-10-12, first 30 days against last 30. Swap the package name to check any row yourself.

The table

Installs, not users, and definitely not patterns evaluated. All figures are my own pulls.

The safety stack is the growth story

Add up the three rows whose job is to prevent a bad regex from running: safe-regex + safe-regex2 + re2js = roughly 208.8M in the last window, from about 64.2M in the first. Meanwhile xregexp — the library that makes writing regexes nicer — grew +18%, the slowest real growth on the page.

That gap is the finding. Nobody is installing more tools to author regular expressions; they are installing tools to inspect them. Two plausible causes and I cannot separate them with this data: user-supplied patterns reaching server code have become a normal attack surface (a ReDoS pattern is a denial-of-service primitive you can paste into a form field), and generated code now emits regexes that nobody reviewed before execution. Both point the same direction — untrusted patterns are common enough to warrant a check on every request path.

safe-regex at +55% against safe-regex2 at +10.9× is a maintenance migration in miniature. The packages share a description and a purpose; the "2" simply stays published. Users moved rather than the market growing — 8.024M to 87.64M is mostly relocation, and I would not read it as ninefold new interest in ReDoS.

Two rows that need explaining, not celebrating

escape-string-regexp at 1.647B is the largest number here and the least glamorous. It escapes . and * and + so a literal string cannot be interpreted as a pattern. A billion and a half monthly installs means it is a dependency of other packages — build tools, routers, log filters, search highlighters. The scale tells you how often code takes a string from the outside world and hands it to new RegExp. That is the same class of mistake ReDoS checks exist for, one level earlier.

re2js at +115× (0.30M → 34.54M) is the most dramatic row and the one I trust least as a signal of preference. RE2's value is guaranteed linear time by giving up backreferences and lookaround. Its growth tracks the security argument above, but a multiple that large off a 0.30M base is also what a single popular framework adding one dependency looks like. I checked nothing beyond the download record, so treat +115× as evidence of a shift, not a measurement of one.

escape-regexp at −40% rounds out the page: same job as escape-string-regexp, smaller, shrinking. Escape-the-user-input is a solved problem with a winner, and the runner-up is losing a fifth of what's left of it.

Choosing

• Any pattern that came from a user or a database: run safe-regex2 on it first, or execute with re2js. Failing the check should reject the request, not log a warning.
• Literal string matched against text: escape-string-regexp. Do not hand-write an escape function; the metacharacter set has surprises.
• Transform or analyse a pattern — optimise it, explain it, transpile it: regexp-tree gives you an AST, which is what +230% of people who need that turn out to have installed.
• Programmatic pattern construction: regexp-util, if you would rather compose objects than concatenate strings and pray.
• xregexp is still fine for named groups and verbose mode in code you own. Just do not expect the data to argue that the category is growing.

What these numbers cannot tell you

• safe-regex and safe-regex2 measure one decision counted twice — a migration between them, not two safety markets.
• A 100× multiple is usually one framework, not a movement. Small bases make large ratios; compare the absolutes (34.54M versus 86.66M) before ranking importance.
• Downloads are not invocations. The number of regexes actually evaluated against untrusted input is unknown and almost certainly far larger than the install count of the tools that check them.

Related

• Regex trends 2026 — adoption across the same window
• Regex alternatives — parsers and matchers when a regex stops fitting
• Regex best practices — backtracking, anchors, and the catastrophic cases