Choosing a password you can actually remember

Most password advice fails before it starts, because it assumes the problem is your memory. It is not. The problem is that the password your brain finds memorable is the same one everyone else’s brain finds memorable — and attackers do not guess per-password, they guess per-pattern, running every name-and-year combination and every dictionary word with a digit appended through billions of attempts per second. The good news: the fix is simpler than the folklore suggests, and it does not require memorizing anything impossible.

Why human-made passwords fail

Humans are predictable in ways that defeat guessing at scale. The most common passwords in every published breach list share the same skeleton: dictionary words, keyboard patterns (qwerty, 123456), names and dates, and predictable transformations of them — the classic “p@ssw0rd” substitution, which is so well known it is a listed pattern in cracking dictionaries. Every substitution rule you can think of (a→@, o→0, i→1) has been catalogued, automated, and run against every leaked list. A password that “looks” complex — “P@ssw0rd!” — is cracked in the same early pass as “password”, because the pattern, not the length, is what the attacker is exploiting.

Worse, the compensation strategy people use is reuse. A password that is hard to remember gets used everywhere, so one breach anywhere — a forum, a marketing list, a vendor with poor security — publishes credentials that attackers replay against every major site within hours. This is the real threat model: not a person hunting your accounts, but automated lists and replays.

What entropy actually measures

The property that resists guessing is not complexity, it is entropy: the number of possibilities an attacker must search. For a password drawn uniformly at random from a set of characters, the formula is simple:

entropy = length × log2(charset size)

Each character from a 94-symbol pool (upper, lower, digits, symbols) adds about 6.55 bits; each character from a 62-symbol pool (letters and digits) adds about 5.95; each lowercase letter adds 4.7. The numbers make the trade-offs visible:

Style	Length	Charset	Entropy
Random lowercase letters	10	26	47 bits
Random letters + digits	10	62	59.5 bits
Random letters + digits + symbols	12	94	78.6 bits
4 random words (7,776-word list)	—	7,776	51.6 bits
6 random words (7,776-word list)	—	7,776	77.5 bits

Two things stand out. First, the difference between “complex” and “long” is written in the arithmetic: adding characters to the pool adds a fraction of a bit each, while adding length adds bits per character. Second, the bit count is only honest when the draw is uniform and random — a dictionary word is not “one of 26 letters”, and applying the formula to a pattern-based password flatters it. The formula measures random draws; the moment a human pattern is involved, the real entropy is whatever the pattern leaks, which is close to zero.

The two strategies that work

Given the math, there are exactly two honest approaches, and they differ by whether you need to memorize the password:

For accounts you must type or recall from memory: a passphrase — several words drawn at random from a known list. This is the strategy behind Diceware and the EFF word lists: a 7,776-word list contributes log2(7,776) ≈ 12.9 bits per word, so six random words give about 77.5 bits. The words are real and common — “truck”, “green”, “novel” — so the passphrase is memorable precisely because the words are mundane, and it is strong precisely because the choice was random. The two properties that matter are random choice and count: the words being ordinary is what makes it rememberable, and the words being independently drawn is what makes it strong. A sentence about your life is the opposite on both counts.

For everything else: a random password you never memorize at all, held by a password manager or vault. This is where a generator earns its keep: an 18-character random string from a 94-symbol pool carries about 118 bits — far beyond any practical guessing attack — and you never need to know it. The only condition is that the vault itself has a strong master passphrase, which is the memorized secret above.

A defensible split: passphrase for the handful of secrets you actually type (vault master, primary email), random per-account passwords for everything else, each unique, none shared.

What the generator is doing when it shows bits

A generator that displays a bit count instead of a colored strength bar is making an honest claim: it is telling you the search-space arithmetic for a uniform random draw from a known pool. The password generator on this site draws from crypto.getRandomValues — the same cryptographically secure source browsers use for TLS key generation — and uses rejection sampling, so every character in the pool is exactly as likely as every other (no modulo bias, the subtle skew that plagues naive generators). It guarantees at least one character from each type you selected, shuffles the result so there is no pattern in where the guaranteed characters sit, and reports entropy as length × log2(charset size) for the configuration you actually chose. The length floor is 8, per NIST SP 800-63B’s minimum for memorized secrets. Nothing is uploaded, logged, or stored — the password is created in memory, copied, and gone. The tool’s honesty is the point: it will never claim “this password is strong” — it shows you the bits and lets the arithmetic speak.

The hash connection: why sites store what they store

A password generator is only half the story; the other half is what happens to the password after you submit it. Reputable sites do not store your password — they store a one-way hash, and the hash generator demonstrates exactly what that is: a deterministic digest like SHA-256("password") = 5e884898da28047151d0e56f8dc62927…, which you can reproduce and compare. The same hash of the same input is identical everywhere, which is how a site verifies your password without keeping it.

But the demonstration carries a warning that is easy to miss: hashing is not protection. SHA-256 is designed to be fast, and speed is exactly the wrong property for password storage — an attacker with a leaked hash database runs billions of guesses per second through the same algorithm. That is why proper password storage uses deliberately slow, salted functions (bcrypt, scrypt, Argon2) that are also one-way but are expensive to run at scale. If you are computing a hash to verify an upload, compare a checksum, or confirm that two systems agree on a document, SHA-256 is the right tool — the hash generator uses the browser’s own WebCrypto implementation and shows both hex and base64 forms of the same digest. If you are deciding where to store user passwords, the conversation should never involve SHA at all. The tools on this site stay out of that trap honestly: the generator produces secrets, and the hasher verifies integrity — the two jobs are different, and mixing them is how passwords leak.

Let the calculator do it

The password generator creates 8–128 character passwords with cryptographically secure local randomness, per-type guarantees, an optional ambiguity filter (no 0/O/1/l/I for printouts), and a truthful bit-count for every configuration. The hash generator computes SHA-1, SHA-256, SHA-384, and SHA-512 digests locally in hex and base64 — with SHA-1 labeled honestly as deprecated, because you should not encounter a security recommendation to use it. Both run entirely in the browser, and neither one ever transmits what you enter.

The one rule

Stop trying to make a password that is both random and memorable in one string — those two goals pull in opposite directions. Instead: random words you can say, for the few secrets you must remember; random characters a vault remembers, for everything else, one per account. The bit count is the measurement, the passphrase is the memory trick, and the generator is the worker. Predictability is the attacker’s only lever — take it away, and the arithmetic is on your side.