The zxcvbn npm package is still functionally solid for password strength estimation, but the original Dropbox library has not seen a release in years and is effectively unmaintained, which is the main reason to think twice before adding it to a new project. The algorithm is excellent. The package around it is aging. Understanding that distinction is the whole story.
What zxcvbn does
zxcvbn is a password strength estimator created at Dropbox and inspired by how real password crackers work. Rather than enforcing the tired "one uppercase, one number, one symbol" rules, it scores a password by estimating how many guesses an attacker would need, accounting for common passwords, dictionary words, keyboard patterns, dates, and predictable substitutions like p@ssw0rd. It returns a score from 0 to 4 plus human-readable feedback, so you can power a rule-free strength meter that actually reflects guessability.
That approach is genuinely good security design. NIST's own guidance moved toward checking passwords against known-weak lists rather than composition rules, and zxcvbn was ahead of that curve.
The maintenance problem
Here is the catch. The original zxcvbn package on npm was last published roughly four years ago. The source is written in CoffeeScript and shipped as CommonJS and AMD modules, which feels dated in a modern ESM and TypeScript codebase. The Dropbox repository is essentially in maintenance-freeze territory, so bug fixes, dictionary updates, and modern packaging improvements are not arriving.
An unmaintained dependency is not automatically a vulnerable one. There is no headline CVE that makes zxcvbn dangerous to run. But "no fixes are coming" is a risk category of its own:
- If a security issue is found, no upstream patch will ship.
- The bundled dictionaries do not get updated as password trends shift.
- It will not adopt improvements in packaging, tree-shaking, or types without a fork.
For supply-chain hygiene, an abandoned package deep in your dependency tree is exactly the kind of thing worth flagging. An SCA tool such as Safeguard surfaces packages that are stale or unmaintained, not just ones with a known CVE, which is where zxcvbn shows up.
Bundle size is the other cost
zxcvbn ships large dictionaries, so the package is heavy, on the order of hundreds of kilobytes minified. On a client-side registration form that is a real performance consideration. Common mitigations are lazy-loading it only on the password screen, or moving strength estimation server-side so the dictionaries never hit the browser bundle at all. Server-side is also more honest: strength checking done purely in the client can be bypassed, so the authoritative check belongs on the backend regardless.
Modern alternatives
If you like the algorithm but want an actively maintained package, the community has responded. The most direct successor is zxcvbn-ts (@zxcvbn-ts/core), a full TypeScript rewrite with strict types, dual CommonJS and ESM output, modular language dictionaries you load only as needed, and a batch of fixes over the original. Its modular dictionaries directly address the bundle-size complaint, because you import only the language packs you actually need.
A reasonable decision framework:
- New project, care about bundle size and types: use zxcvbn-ts.
- Existing project already on zxcvbn, working fine: it is not urgent to rip out, but note it as tech debt and avoid depending on it for anything security-critical without a server-side check.
- Any project: never treat a client-side strength score as an authorization control. It is UX guidance, backed by a server-side policy.
Using it responsibly today
If you keep or adopt zxcvbn, pin the version, monitor it for advisories the way you would any dependency, and combine it with server-side enforcement plus a check against a breached-password list such as Have I Been Pwned's k-anonymity API. The strength meter guides users toward better choices; the backend policy is what actually protects the account. Our academy covers layering these controls in a real authentication flow.
FAQ
Is the zxcvbn npm package still safe to use?
It is safe in the sense that there is no known critical vulnerability, but the original Dropbox package is effectively unmaintained, so no future fixes or dictionary updates will arrive. Treat it as legacy and prefer an actively maintained port for new work.
What is the best maintained alternative to zxcvbn?
zxcvbn-ts (@zxcvbn-ts/core) is the most direct successor: a TypeScript rewrite with modern packaging, strict types, and modular dictionaries that reduce bundle size.
Why is zxcvbn's bundle size a concern?
It bundles large word dictionaries, adding hundreds of kilobytes to a client bundle. Lazy-load it on the password screen, use a modular alternative, or run strength estimation server-side to avoid shipping the dictionaries to browsers.
Can I rely on zxcvbn for password security?
Only as user-facing guidance. A strength score computed in the browser can be bypassed, so enforce your real password policy server-side and check candidates against a breached-password database.