Password Generator

Make a strong, random password to use for a website, account, or login.

Group similar characters
Keeps all the CAPITALS together, all the numbers together, and so on — easier to type on a phone.
Avoid confusing characters
Leaves out characters that look alike, like 0 (zero) and O (letter), or 1 (number), l (lowercase L), and I (capital i).
Capitalize each word
Example: Coffee-Window-Basket
Add a number at the end
For websites that require at least one number.
Your new password:
What do these numbers mean?

The "bits" number measures how many guesses it would take to crack the password. Each bit is like a coin flip's worth of uncertainty, and every extra bit doubles the number of possible passwords — so the guesses needed grow explosively, not steadily. Going from 40 to 80 bits isn't twice as strong; it's roughly a trillion times more combinations to search through.

Here's roughly how long that takes a computer trying billions of guesses per second:

BitsTime to crack
20Instantly
40About a minute
50About a day
60About 2 years
80Millions of years
100Trillions of years
128+Longer than the universe has existed

This is a worst-case estimate — real websites usually slow attackers down far more than this.

The math itself is just arithmetic anyone can check: each extra bit of entropy doubles the number of guesses needed, so total guesses = 2^bits. Dividing that by an attacker's guess rate gives the time shown above. The part worth sourcing is the guess rate (10 billion/sec) — that's a round, conservative figure based on real hardware. Hashcat's own documentation, the standard open-source tool security researchers use to benchmark password-cracking hardware, shows an example benchmark run hitting roughly 16 billion MD5 hashes per second — and that was on GPU hardware from several years ago, so current high-end hardware benchmarks even higher for fast, unsalted hashes. It's a worst-case number: well-designed sites use slower hashing (bcrypt, Argon2, scrypt) that cuts attacker speed by orders of magnitude.

For the offline-attack threat model this table assumes — and the general idea of measuring secrets in bits of entropy — see the U.S. government's NIST SP 800-63B-4 (once open, search the PDF for "Password Verifiers" to jump to Section 3.1.1.2). It requires stored passwords to be salted and hashed specifically to make offline guessing expensive, and uses explicit bit-entropy thresholds elsewhere in the document (e.g. cryptographic keys need at least 112 bits). Worth noting: NIST's current guidance has moved away from scoring user-chosen passwords by entropy — it now favors simple length minimums and blocklists over composition rules (Sec. 3.1.1.1, findable the same way). The entropy math here is still valid, just applied a bit differently than NIST currently recommends for how sites should design their password policies.

How much is enough?

For most everyday accounts, "Good" or better is plenty. Save "Excellent" for the accounts that matter most:

A note on tool use

This tool protects your password from ever leaving your device — but device-level security (keeping your browser and system updated, avoiding untrusted extensions) still matters here, the same as with any password tool.