The zxcvbn Algorithm: Measuring Password Strength the Way an Attacker Would

Type P@ssw0rd into the sign-up form of a typical website and the strength meter will often turn green. It has an upper-case letter, lower-case letters, a digit and a symbol, so by the usual rules it ticks every box. It is also one of the first passwords any attacker tries, because it is nothing more than the word "password" with the most predictable changes made to it.

The trouble is that those rules measure the wrong thing. They count which kinds of character a password contains, when what matters is how many guesses it would take an attacker to find it. zxcvbn is a password strength estimator built around that second question. It looks for the words, names, keyboard patterns, dates and tricks that real people use, and asks how quickly an attacker who knows those habits would get there. This article explains where zxcvbn came from, how it works, where it falls short, and how SyncBack V12 uses it.

The problem with counting character types

For decades, the standard advice has been a set of composition rules: at least eight characters, with at least one upper-case letter, one lower-case letter, one digit and one symbol. The appeal is obvious. The rules are easy to explain and easy to check, and in theory each extra kind of character multiplies the number of possible passwords.

In practice people respond to the rules in very predictable ways. The capital letter goes at the start. The digit goes at the end, and it is usually a 1 or a year. The symbol is an exclamation mark, or replaces a letter it looks like: @ for a, 0 for o, $ for s. Attackers know all of this, and their cracking tools apply exactly these changes to their word lists. So the rules make passwords harder for people to remember while making them only slightly harder to guess. Password1! satisfies every rule above, and zxcvbn estimates that it would fall in about 18,000 guesses.

Standards bodies have caught up. The current US guidance, NIST SP 800-63B-4 (August 2025), says that composition rules such as requiring a mix of character types must not be imposed at all. Instead, new passwords should be checked against a blocklist of common, expected and breached passwords, and people should be given guidance to help them choose a strong one. Estimating strength realistically, and explaining the result, is exactly what zxcvbn was designed to do.

Where zxcvbn came from

zxcvbn was written by Dan Wheeler, then an engineer at Dropbox, and introduced in April 2012 in a post on the Dropbox tech blog titled zxcvbn: realistic password strength estimation. His argument was that strength meters could help people choose better passwords, but that most of the meters in use at the time did more harm than good, because they rewarded the very patterns attackers exploit.

The name is itself a password, and a bad one: z, x, c, v, b and n are the first six letters along the bottom row of a QWERTY keyboard. It is the kind of keyboard walk that looks random but is among the first things an attacker tries, and zxcvbn is designed to catch it.

In 2016 Wheeler published a peer-reviewed paper, zxcvbn: Low-Budget Password Strength Estimation, at the 25th USENIX Security Symposium. It tested zxcvbn against leaked password data and four modern guessing attacks, and found its estimates accurate and conservative at the low end, where the guess counts matter most for stopping online attacks. It also showed that about 1.5 MB of compressed data is enough to estimate the best known attacks accurately up to around 100,000 guesses, and that zxcvbn could be added to a website or app with a few lines of code.

The original JavaScript library is open source under the MIT licence and is available on GitHub. Its last release, version 4.4.2, came out in February 2017. It has since been ported to many other languages, including Python, Java, Go, .NET and Rust, and it remains one of the most widely used password strength estimators.

How zxcvbn works

zxcvbn treats a password the way a cracking tool does. An attacker does not try every possible combination of characters in order. They try the most likely passwords first: common passwords, then words and names, then those words with capital letters and substitutions, then words joined to dates and numbers, and so on. zxcvbn estimates how far down that list a password sits. It does this in four steps.

Step 1: finding the patterns

First, zxcvbn searches the password for every piece of it that matches something an attacker would try. The pieces can overlap, and at this stage it keeps all of them. It looks for:

• Dictionary words. It has six ranked lists, with the most common entries first: 30,000 common passwords, 30,000 common English words taken from Wikipedia, 19,160 words common in US television and film, 10,000 surnames, and 3,712 female and 983 male first names. Matching ignores capital letters.
• Reversed words, such as drowssap.
• "L33t" substitutions, where symbols and digits stand in for letters that look like them: @ or 4 for a, 3 for e, 1 or ! for i, 0 for o, $ or 5 for s, and so on. p@ssw0rd is found as the word "password".
• Keyboard patterns, called spatial matches, such as qwerty, asdfgh or 1qaz2wsx, on four layouts: QWERTY, Dvorak, and the numeric keypads of PC and Mac keyboards. It records how many times the pattern changes direction and how many shifted characters it uses.
• Repeats, such as aaaaaa or abcabcabc.
• Sequences, such as abcdef, 13579 or 9876, in either direction.
• Years and dates, in many formats and with or without separators, such as 1990, 07/10/2026 or 071026.
• User inputs. A website or program can pass in extra words that matter for that particular password, such as the person's user name, email address or the name of the service. They are treated as a dictionary of their own, because they are among the first things an attacker who targets you would try.

Anything that matches none of these is treated as random characters, which zxcvbn calls brute force.

Step 2: estimating the guesses for each pattern

Next, zxcvbn estimates how many guesses an attacker would need to find each piece. The estimate depends on the kind of pattern:

• A dictionary word starts from its rank in its list. "password" is second in the common passwords list, so it starts at 2 guesses. A word ranked 20,000th starts at 20,000. The estimate is then multiplied up for capital letters (only slightly for the usual ones, such as a capital at the start or all capitals), for each l33t substitution, and by 2 if the word is reversed. P@ssw0rd comes out at 2 for the word, times 2 for the capital P, times 4 for the two substitutions, which is 16 guesses.
• A keyboard pattern is estimated from the number of starting keys on the layout, the average number of neighbouring keys, the length, and the number of turns, so a long walk with several changes of direction costs more than a straight row.
• A repeat costs the guesses for the repeated unit times the number of repeats.
• A sequence costs very little, especially one that starts at an obvious point such as a, z, 0, 1 or 9.
• A year or date is estimated from how far it is from the current year (at least 20 years' worth), times 365 days for a full date, so dates close to today are treated as the most likely.
• Brute force costs 10 guesses per character. That is far fewer than the 95 printable characters on a keyboard, and the low figure is deliberate. It keeps zxcvbn on the cautious side when it meets characters it cannot explain.

Step 3: finding the attacker's cheapest route

A password can usually be split into pieces in many different ways. correcthorsebatterystaple could be read as four words, or as "correct" followed by a long run of random letters, or in dozens of other ways. An attacker will find it by whichever route is cheapest, so zxcvbn looks for the split that covers the whole password with the fewest total guesses. It does this efficiently with a technique called dynamic programming, building up the best answer for each length of the password from the best answers for the shorter lengths.

For a split into some number of pieces, it multiplies the guesses for the pieces together, then multiplies by the number of different orders the pieces could be tried in, and adds a small allowance for the attacker not knowing in advance how many pieces there are. For the four words in correcthorsebatterystaple that is roughly:

correct (1,140) × horse (701) × battery (2,197) × staple (6,467)
  × 24 possible orders, plus a small allowance
  = about 270,000,000,000,000 guesses

This step is what lets zxcvbn see a password as an attacker would. Each word on its own is common, but four of them chosen at random multiply into a very large number. On the other hand, a long password made of one common password repeated, or a word with "123" on the end, gains very little from its length.

Step 4: turning guesses into a score and advice

The final estimate of guesses is turned into a score from 0 to 4:

A number of guesses means little on its own, so zxcvbn also converts it into crack times for four attack scenarios:

• Online, throttled: 100 guesses an hour, for a service that limits how often you can try to log in.
• Online, unthrottled: 10 guesses a second, for a service that does not.
• Offline, slow hash: 10,000 guesses a second, for an attacker who has stolen a password hash protected with a deliberately slow algorithm such as bcrypt or PBKDF2.
• Offline, fast hash: 10 billion guesses a second, for a fast hash such as SHA-256 or MD5, or an attacker with a lot of hardware.

The difference between online and offline attacks is the most important idea in password strength. Online, the service stands between the attacker and your password and can slow them down or lock them out. Offline, the attacker has a copy of something they can test guesses against on their own hardware, as fast as they can and for as long as they like. An encrypted backup file is in the offline category: anyone with a copy of the file can attack its password without anyone knowing.

Finally, zxcvbn explains itself. For weak passwords it gives a warning that says why, such as "This is a top-10 common password", "Straight rows of keys are easy to guess", "Dates are often easy to guess" or "Common names and surnames are easy to guess", and suggestions such as "Add another word or two. Uncommon words are better" or "Predictable substitutions like '@' instead of 'a' don't help very much". Telling someone why a password is weak is far more useful than a red bar.

Worked examples

These results come from zxcvbn 4.4.2, the final release of the original library. The crack times are zxcvbn's own, rounded as it rounds them.

A few things stand out. Two of the first eight rows, P@ssw0rd and Password1!, meet every traditional composition rule, yet all eight would fall in seconds to an offline attack. Substitutions, reversal and a trailing "!" barely move the estimate. And the passphrase of four ordinary words, which contains no capitals, digits or symbols at all, is rated as one of the strongest.

Look too at the fast-hash column. Even passwords zxcvbn rates as very strong can fall within minutes, hours or days to an attacker testing 10 billion guesses a second. That is why it matters how a password is stored, and why a password protecting something an attacker can take away and work on, such as an encrypted file, should be as strong as you can make it.

What zxcvbn gets right

• It measures what matters. It estimates the guesses a realistic attacker needs, not how many kinds of character appear.
• It rewards length and unpredictability, not decoration. A long passphrase scores well without a single symbol, and a short word dressed up with symbols does not.
• It explains itself. The warnings and suggestions tell people what to change, which is more helpful than a rule they have to work around.
• It is fast. A typical password takes a fraction of a millisecond to check, so it can be used while someone is typing.
• It is private. It runs entirely on the device. The password does not have to be sent anywhere to be checked.
• It is cautious where it is unsure. Characters it cannot explain are counted at only 10 guesses each, so a truly random password tends to be underrated rather than overrated.
• It is open and well studied. The code, the method and the peer-reviewed evaluation are all public.

Where zxcvbn falls short

zxcvbn is an estimate, and it is only as good as what it knows. It is worth understanding where it can be wrong.

• It cannot see what is not in its lists. The xkcd comic that popularised "correct horse battery staple" also used Tr0ub4dor&3 as its example of a hard-to-remember but weak password, a misspelled word with predictable substitutions and a digit and symbol added. zxcvbn rates it 4, very strong, because the misspelling "troubador" is not in any of its lists, so it treats the whole thing as 11 random characters. An attacker with a bigger dictionary would not.
• Its lists are frozen in time. zxcvbn 4.4.2 dates from 2017, and its lists are older still. Passwords that have become popular since, and the names of newer films, games, celebrities and products, are unknown to it. It does not even recognise years after 2019 as years: Summer2016 scores 1 (about 24,000 guesses), but Summer2026 scores 2 (about 2 million), because 2026 is not seen as a year.
• It is English-centric. The words and names come mostly from English and US sources. A common word or name in another language may be treated as random characters and rated much higher than it should be.
• It does not know about you. Unless the program using it passes in your user name, company or the name of the service as user inputs, zxcvbn cannot know that SyncBack2026! is an obvious choice for a SyncBack password. Without user inputs it scores 4. With "SyncBack" given as a user input, it drops to 2. Your pet's name, your street and your favourite team are invisible to it either way.
• It does not know about breaches. A password that looks random but has already been leaked from some website, and is therefore in every attacker's list, can still score highly. Checking against a list of breached passwords catches what zxcvbn's own lists miss, which is why the two work best together.
• The high end is rough. The 2016 paper found zxcvbn accurate at the low end, which is where the decisions that matter most are made. The difference between a score of 3 and 4, or between "3 years" and "centuries", is a much rougher estimate, and the crack times assume a particular rate of guessing that may not match a given attacker.

zxcvbn in SyncBack V12

SyncBack stores passwords for many things: encrypted and compressed backups, network shares, FTP and SFTP servers, cloud services and email accounts. From a forthcoming release of version 12, SyncBackPro, SyncBackSE and SyncBackFree can check a password when you click the button next to it, and zxcvbn is the first part of that check.

A faithful port, run locally

SyncBack is written in Delphi, not JavaScript, so we ported zxcvbn 4.4.2 to Delphi, with the same word lists and keyboard layouts built into the program. To make sure the port behaves exactly like the original, our tests run about 13,800 passwords through both: common passwords, words with every kind of capitalisation, l33t substitutions, reversed words, keyboard walks on all four layouts, repeats, sequences, dates, random text, emoji and very long passwords. For every one, the port must produce the same score, warning, suggestions and crack times as the original, and must split the password into the same pieces. The tests also check the port on every platform SyncBack is built for, for thread safety, speed and memory use.

The strength check runs entirely on your computer and never contacts the network. It analyses the first 100 characters of a password, which is more than enough for any password a person types.

How to use it

Password boxes in a profile's settings have a small button at their left-hand end. What it does depends on whether the box is empty:

• If the box is empty, the button offers to Generate Password. SyncBack asks how long the password should be (20 characters by default), creates a random password and copies it to the clipboard so you can store it safely, for example in your password manager. Click OK to put it in the password box. The clipboard is cleared automatically when the message closes.
• If the box contains a password, the button offers to Check Password. SyncBack first runs zxcvbn on it. If zxcvbn rates the password Very weak or Weak (a score of 0 or 1), SyncBack tells you the password is insecure, with zxcvbn's reason when it gives one, and goes no further. If the password passes, SyncBack asks whether you would also like to check online whether it is known to have been compromised.

The check only ever warns. If you choose to keep a password, SyncBack will use it. It is also not available for a password that comes from a secrets manager through SyncBackPro's Secrets Manager, since the box then holds a reference to the secret rather than the password itself.

The online breach check

The online part covers zxcvbn's biggest blind spot. It uses the Pwned Passwords service from Have I Been Pwned, which holds well over a billion passwords exposed in real data breaches. Your password is never sent. SyncBack turns it into a SHA-1 hash, a one-way fingerprint, and sends only the first 5 of the hash's 40 characters. The service replies with every breached hash that starts with those 5 characters, padded with dummy entries, and SyncBack looks for a match on your own computer. The service cannot tell which password you checked or whether it was found, and 2BrightSparks receives nothing from the check. Nothing is sent unless you choose to check, and no password is ever checked during a profile run. Our privacy article describes this in more detail.

If the password is found, do not use it, however strong it looks. If it is not found, that is good to know, but it only means the password has not appeared in a known breach. It does not make a weak password strong, which is why the zxcvbn check comes first.

Which passwords matter most

Not every password SyncBack stores faces the same risk:

• Passwords that encrypt your backups, whether Zip or 7-Zip, face offline attacks. Anyone who gets a copy of the backup, from a lost USB drive or a compromised cloud account, can try passwords against it as fast as their hardware allows, with no lockouts and no one watching. Aim for a password zxcvbn would rate Very strong, and do not settle for one that merely avoids a warning. A long random password from the generator, or a passphrase of five or more random words, is the safest choice. See Data Encryption and Securing Your Backups for more.
• Account passwords for FTP servers, cloud services and email are usually attacked online, where the service can limit attempts. They still matter, especially if the same password is used anywhere else, but often you do not get to choose them, and the account's own protections, such as key-based SFTP authentication, matter as much as the password.

Choosing a password that scores well

zxcvbn's results point to the same practical advice that current guidance gives:

• Length beats complexity. Adding words or characters helps far more than swapping letters for symbols.
• Let something random choose. People are bad at being random. A password generator, or words picked at random from a long list (by dice, for instance), will beat anything chosen by hand.
• Avoid anything about you: names, birthdays, places, teams, and the name of the program or service the password is for.
• Never reuse a password. Once one site leaks it, it is in every attacker's list, and every other account that uses it is at risk.
• Use a password manager so that long, random, unique passwords do not have to be remembered. SyncBackPro can read passwords directly from Bitwarden, 1Password and Dashlane, so they do not have to be typed into a profile at all.

Conclusion

zxcvbn changed how password strength is measured by asking the question an attacker asks: how quickly could this be guessed? Its answer comes from finding the common passwords, words, names, keyboard patterns and dates that people really use, and working out the cheapest way to combine them. That makes it far better than counting character types at telling weak passwords from strong ones, and its plain-English advice helps people do something about it.

It is not perfect. Its lists are dated, it cannot see what it does not know, and it knows nothing about passwords that have already leaked. Combined with a breach check, though, it gives a realistic picture of how safe a password is. In SyncBack V12 the two together take a click to run, and neither ever sends your password anywhere.

Further reading: Dan Wheeler's original Dropbox blog post and USENIX Security paper, the zxcvbn source code, NIST SP 800-63B-4, and our articles on hashing and backup software and your privacy.