How Long Should a Password Be in 2026?

The short answer is sixteen characters as a floor, and twenty or more for anything that guards money, email or infrastructure. The longer answer is more useful, because it explains why the advice you were given a decade ago about mixing symbols and swapping letters for numbers was mostly wasted effort.

What entropy actually measures

Entropy is the number of guesses an attacker would need on average, expressed in bits. Each additional bit doubles that number. It is calculated from the size of the alphabet you drew from and how many characters you drew, not from how complicated the result looks to a human eye.

entropy = length × log2(alphabet size)

12 chars, lowercase only   ≈  56 bits
12 chars, all four types   ≈  79 bits
20 chars, all four types   ≈ 131 bits

Notice which change did more work. Going from lowercase to the full alphabet added about twenty-three bits. Going from twelve characters to twenty added over fifty. Length is multiplicative in that formula, which is exactly why it wins.

Why the old complexity rules backfired

Rules demanding an uppercase letter, a digit and a symbol were designed for humans inventing passwords from memory. Humans respond predictably: the capital goes first, the digit and the symbol go last, and a letter gets swapped for a lookalike. Cracking tools have modelled those habits for years, so the real entropy of such a password is far below what the formula suggests.

This is why current guidance from NIST removed mandatory composition rules and mandatory periodic rotation, and emphasised length and screening against known-breached passwords instead.

Online guessing versus offline cracking

The numbers below assume the worst case, which is an attacker who has stolen a database of password hashes and can test candidates on their own hardware at billions of attempts per second. Against a live login form the picture is very different: rate limiting and lockouts cap an attacker at a handful of guesses, so even a mediocre password survives. You cannot choose which situation you will be in, because you do not control how the other end stores your password. Assume the offline case and the online case takes care of itself.

Choosing a number

• Under 50 bits: treat as broken. Recoverable by a motivated attacker with commodity hardware.
• Around 70 bits: acceptable for low-value accounts behind rate limiting.
• Around 100 bits: comfortable for anything you would be upset to lose.
• Over 128 bits: beyond brute force for the foreseeable future. Further length buys nothing.

A twenty-character random password using upper case, lower case, digits and symbols lands around 131 bits. That is the practical sweet spot: past the point where brute force is meaningful, and short enough that fields and legacy systems will still accept it.

The part that matters more than length

Reuse defeats everything above. A 131-bit password used on two sites is only as strong as the weaker site protecting it, and breaches are how most accounts are actually lost. Generate a different random password for every account, store them in a password manager, and reserve the one long passphrase you can remember for unlocking the manager itself.