Password generator

Each bit of entropy doubles the number of guesses an attacker would need to brute-force the password. 1 bit = 2 possibilities, 10 bits = ~1,000, 30 bits = ~1 billion, 60 bits = ~1 quintillion (a billion billion).

The number you see beneath the generated password is the attacker’s worst case — the upper bound on how many guesses they’d need to be guaranteed a hit. In practice they’d find it in roughly half that many tries, on average.

Depends on what the password protects and how long it lives.

• Short-lived shared secret (one-time link that auto-expires in 24h): 40 bits is plenty.
• Account password with MFA (a vault entry, an admin login): 60+ bits.
• Encryption key or anything long-lived against a determined attacker: 80+ bits.
• “Very strong” on the meter (90+ bits): overkill for almost everything.

A modern GPU can guess ~10 billion times per second for a fast hash. That makes 30 bits brute-forceable in seconds and 40 bits in minutes — but only if the attacker has the password hash to attack offline. For online attacks (login forms, rate-limited APIs), 40 bits is genuinely fine.

Random when the password lives in a password manager and you only need to copy/paste it. Maximum entropy per character, but hard to type and impossible to dictate.

Memorable when the password might need to be typed back (rare for vault entries) or read out loud. Word-based passphrases (“Forest Canyon Thistle Garnet Mountain”) reach the same strength as random passwords at much greater length, in exchange for being human-rememberable.

Both modes are appropriate for serious credentials — vault entries, admin accounts, anything that protects a real asset.

They are weaker than Random — but that’s the wrong comparison to draw.

These two modes exist for credentials that have to be relayed verbally and live in physical proximity to the attacker: guest WiFi passwords, conference-room kiosk PINs, AV remote codes. A 20-character random WiFi password gets written on a sticky note next to the router — which defeats its own entropy. A memorable-but-mixed password like Cambridge#23! matches the actual threat model: the realistic adversary is physically nearby, the credential will end up written down anyway, and rotation is infrequent.

Use Random / Memorable for things that protect real assets. Use Affix / From word for things that get dictated. They’re four tools for two different jobs, not four points on a single security-vs-convenience axis.

Both start with a word you provide. They differ in how they obscure it.

• Sandwich keeps the word intact and wraps it with random characters. cambridge → 9k!Cambridge#3X. The word stays readable — easy to dictate over the phone.
• Substitution mutates the word’s letters with leet swaps (a→4, e→3, i→1) and random case mixing. cambridge → cA4Br1Dg3#7K. Harder to dictate, but looks more “password-y” to systems with strict complexity rules (must contain mixed case + digit + symbol).

Default to Sandwich. Switch to Substitution only when a target system rejects Sandwich-style output for not being complex enough.

Removes 0 (zero), O (capital o), 1 (one), l (lowercase L), and I (capital i) from the alphabet the generator draws from. These look identical in most fonts and cause people to mis-type passwords.

The trade-off is slightly less entropy per character (you lose 5 of ~62 alphabet members), but the convenience of “I read it back correctly the first time” usually wins. Recommended for any password that gets typed or dictated.

Yes. The generator runs entirely in your browser — there is no server-side step. Nothing you type, generate, or copy ever leaves this page.

Random characters come from crypto.getRandomValues(), the browser’s built-in cryptographic random-number generator. This is the same primitive password managers and banks use. It is not Math.random(), which is predictable enough that a determined attacker can recover its seed.

If you want to verify: open your browser’s view-source on this page, check that the only outbound traffic is loading the page itself, and that the JS uses crypto.getRandomValues rather than Math.random.

No. Generated passwords are never stored or transmitted.

The page does remember your settings (which mode you picked, length, complexity, etc.) in your browser’s local storage so you don’t have to re-pick on every visit. Only the settings, never the passwords themselves.

Not directly — this page is a generator, not a sender. To share a password securely with someone (one-time link, auto-expire, identity verification, audit trail), sign in to Secure Share and create a new exchange.

The generator is also embedded inside the create-exchange form, so you can generate + send in one flow without copy-pasting between this page and the admin.

Reasonable question. Short answer: no.

• The generator is a calculator that runs in your browser. No password ever touches our server.
• There’s no account, no logging of generator output, no analytics tracking what you generated.
• The source code is auditable (right-click → View page source). You can verify it doesn’t phone home.

We host it publicly because (a) it’s useful, (b) it costs nothing to run, and (c) the alternative — every customer reinventing their own password generator from scratch — usually produces worse passwords.

If you want maximum paranoia: use the built-in generator in your password manager (1Password, Bitwarden, KeePassXC). They work the same way — client-side, cryptographic RNG — and you avoid trusting any third party at all.