What zxcvbn actually measures (and what it does not)#
zxcvbn is not a simple character-based entropy calculator. It knows about common passwords, keyboard walks (like qwerty), repeated patterns, dates, English words, common names, and other structures people actually use when creating passwords, then estimates how many guesses a smart attacker would need to find it. A password that has high character entropy but is a common pattern will score poorly, which is exactly what you want a checker to catch.
What zxcvbn does not model: slow hashes, salting, rate limiting, or account lockout. The crack-time estimates assume the attacker has the raw password or a fast hash of it — the same assumption the password-generator tool makes — so they are best read as a comparison between passwords, not a literal clock.
Why character entropy still matters#
The tool shows both the zxcvbn score and a separate character-level entropy (length × log₂(charset size)). These two numbers measure different things: zxcvbn knows what pattern the password follows, while character entropy treats every character as equally random. A randomly generated password will score high on both; a password made of two common words concatenated with a digit will score much lower on zxcvbn than its character entropy suggests, because zxcvbn recognises the words.
Looking at both numbers together gives you the most useful picture: if the zxcvbn score is telling you "very weak" but the character entropy is saying "strong", the problem is almost certainly a recognisable pattern in the password, and the feedback section will tell you exactly what.
The difference between "offline fast" and "online" crack times#
The tool shows two crack-time estimates: one assuming a fast offline attack (10 billion guesses/second) and one assuming a slow, properly-hashed scenario (10 thousand guesses/second, such as bcrypt or Argon2). The fast estimate assumes an attacker who has already obtained the password hash and is cracking it on GPU hardware with no rate limiting — the worst-case realistic scenario.
The slow estimate models a service that uses a purpose-built password hash and rate-limiting on login attempts, which is what responsible services actually do. The gap between the two numbers — often many orders of magnitude — is exactly why slow hashing exists, and why writing "password strength does not matter if the server hashes properly" is misleading: the attacker chooses which hash to attack, not the service.
Nothing leaves your browser#
zxcvbn is loaded from a CDN on first page visit, but once it is in the browser the entire analysis runs locally — no keystrokes, no passwords, and no analysis results are sent anywhere. You can disconnect from the internet after the page loads and it will keep working. The same zero-exfiltration principle applies to every tool on this site.