Are Password Generators Safe? I Tested 6 of Them

Yes — the password generators I tested are safe, with one caveat. On October 19, 2026, I generated 600 passwords across 6 free generators (Bitwarden CLI, PasswordWolf.com, OpenSSL, Python's secrets module, xkcdpass, and EFF Diceware), and every single one produced strong, uniformly random output with zero duplicates. But the defaults are not equal: Bitwarden's CLI ships with symbols turned off and a 14-character default, while NordPass's web generator defaults to 20 characters with everything on. The generator matters less than the settings you leave on.

How I tested this

Everything below ran on my own machine (Ubuntu 24.04.5 LTS, Python 3.12.3) on 2026-10-19:

• Samples: 100 passwords from each of 6 generators = 600 total, all saved to disk with the analysis script.
• Tools: Bitwarden CLI v2026.10.0 (bw generate), PasswordWolf.com JSON API, OpenSSL 3.0.13 (openssl rand -base64), Python 3.12 secrets.token_urlsafe, xkcdpass 1.30.0, and EFF Diceware passphrases generated with Python's secrets module from the EFF large wordlist (7,776 words, verified line count).
• Measurements: observed charset size, theoretical entropy, and empirical per-character entropy (Shannon entropy of the actual batch — if the generator is biased, this number drops below the ideal).
• Strength math: same convention as my earlier password-strength tests — entropy in bits = length × log₂(charset size), crack time = 2^bits ÷ 10^10 guesses/second (a pessimistic fast-hash scenario; real sites using bcrypt are far slower, per Hive Systems' 2026 table).

Test 1: 600 passwords, measured

In plain English: all six generators produced excellent output — no duplicates, no detectable bias, and every batch strong enough to outlast the universe.

*At 10 billion guesses/second against a fast hash — the pessimistic scenario.

The column I haven't shown is the bias check: empirical per-character entropy of each batch. Bitwarden measured 6.10 bits/char against an ideal 6.13 (log₂70); PasswordWolf 6.22 against 6.27; OpenSSL and Python's secrets 5.98 and 5.97 against 6.0. No detectable skew in any of the six — a biased generator would be a weaker one, and none of these are.

Two honest corrections to the table. First, the passphrase rows need different math: word-based passwords get their entropy from the word list, not the character set — 4 words × log₂(7776) = 51.70 bits for xkcdpass, 5 × log₂(7776) = 64.62 bits for Diceware. (I made the per-character mistake in an earlier draft of my own notes; the per-word math is the correct one, and it matches the xkcd #936 analysis.) Second, xkcdpass 1.30.0 ships with the EFF long wordlist built in — I verified the word file it actually used has exactly 7,776 entries, so the 51.70-bit figure is measured, not assumed.

The 4-word passphrase at ~4.5 days looks weak next to the others, but remember the assumption: that's 10 billion guesses per second against a fast hash. Against bcrypt at a sane work factor, Hive Systems measured an 8-character password surviving 2 weeks — a 51.7-bit passphrase survives centuries in practice. And the 5-word Diceware passphrase at 64.62 bits is the sweet spot for anything you must memorize: ~90 years even under my pessimistic math.

Test 2: is the randomness actually random?

A generator is only as safe as its random number source. The classic failure is Math.random() — fine for games, not for secrets, because it's predictable. So I audited what the tools actually use:

• Bitwarden CLI: I inspected the installed v2026.10.0 package's bundled source map on my machine. The password generator routes through an SdkRandomizer backed by Bitwarden's SDK SdkRandomNumberClient().gen_range() — the WebCrypto getRandomValues path (7 references in the bundle), not Math.random() (the 2 Math.random hits in the bundle are outside the generator code). Bitwarden is also fully open source, so this is independently checkable.
• PasswordWolf.com: their generator page states generation happens client-side in JavaScript: "The generator creates the password on the client side so that none of the passwords are sent over the Internet to be sniffed." Client-side generation is the right design — the password never leaves your browser.
• OpenSSL / Python secrets / xkcdpass: these use the OS cryptographic RNG (getrandom() on Linux) by documented design — the same source TLS keys come from.

I did not audit the closed-source web generators' JavaScript (NordPass, 1Password, Dashlane) — that would require executing their pages, which I didn't do. What I could verify is their stated defaults (next section).

Test 3: the defaults audit — this is where it matters

A generator's quality means little if its out-of-the-box settings are weak. Here's what each tool gives you before you touch anything:

Bitwarden's CLI default deserves a closer look, because Bitwarden is the generator I'd otherwise recommend most strongly. Fourteen characters from 62 symbols (no symbols by default) is 14 × log₂(62) ≈ 83.4 bits — about 38 million years under my pessimistic crack math. That is still completely fine in practice. But it's noticeably weaker than the same tool one flag away (-s --length 20 gives 122.6 bits, which is what I tested), and a user who never reads the help text gets the weaker one silently. Defaults are a security decision, and this one is merely okay rather than great.

The NIST password guidelines (SP 800-63B) don't mandate a specific generated length, but the industry consensus from the data above is clear: 16+ random characters with symbols, or 5+ Diceware words, and you're done worrying.

What makes a password generator safe (checklist)

From the tests above, the things that actually matter:

1. Cryptographically secure randomness — WebCrypto, OS CSPRNG, or a documented equivalent. Never Math.random().
2. Client-side generation — the password should never travel over the network. (This is also why I generated my test batches locally or via APIs only for measurement, and never typed a real password into any site.)
3. Sane defaults — 16+ characters, symbols included, or a proper word list. Check before you trust.
4. Unique per site — a perfect generator used to make one password for everything is still a single point of failure. Pair it with a password manager.

FAQ

Are online password generators safe to use? The reputable ones are. My tests found no bias, no duplicates, and proper randomness in all six. Prefer generators from established security companies or open-source tools, check that generation happens client-side, and verify the default length is at least 14–16 characters.

Is a password manager's generator better than a website's? Slightly: it's auditable (Bitwarden's is open source — I verified its crypto RNG in the installed package), and the password lands straight in your vault with no copy-paste step. A good standalone web generator with client-side generation is fine too.

How long should a generated password be? 16 random characters with symbols (96 bits) is overkill for any realistic attacker — that's 250 billion years under pessimistic assumptions. If you must memorize it, use 5+ Diceware words instead (~90 years pessimistic, centuries in practice).

Are passphrase generators like xkcdpass safe? Yes, as long as the words are picked randomly from a large list by the computer — never words you choose yourself. xkcdpass 1.30.0 uses the 7,776-word EFF list, giving 51.7 bits for 4 words. Use 5+ words for important accounts.

Conclusion

All six generators I tested are safe to use — the randomness is real, the output is unbiased, and even the weakest default I found (Bitwarden CLI's 14 characters, no symbols) is still far beyond what any realistic attacker can brute-force. The practical takeaway: pick any reputable generator, bump the length to 20 characters with symbols on (or use 5+ Diceware words for things you type), and store the result in a password manager. The generator you use matters far less than using one at all — and never reusing passwords.

How this article was made

Tested on 2026-10-19 on Ubuntu 24.04.5 LTS (CPU-only VM): Bitwarden CLI v2026.10.0 (npm), OpenSSL 3.0.13, Python 3.12.3, xkcdpass 1.30.0 (pip venv), EFF large wordlist from eff.org (7,776 lines verified). I generated 100 passwords per generator (600 total; Bitwarden via 100 bw generate invocations, PasswordWolf via one ?length=16&repeat=100 API call, the rest via shell/Python loops) and analyzed charset size, batch Shannon entropy, duplicates, and crack time with a Python script. The Bitwarden RNG finding comes from inspecting the installed package's bundled source map (sdk-randomizer.ts → SdkRandomNumberClient). Default settings were read from bw generate --help and the NordPass, Dashlane, and PasswordWolf generator pages (all fetched 2026-10-19). The closed-source web generators' JavaScript was not executed or audited — only their documented defaults are reported. This article was written with AI assistance (Tiny, UnlockProof's AI assistant) and every number in it comes from the test run described above.