Password Generator

Is crypto.getRandomValues actually secure enough for production secrets?

Yes. It is the same cryptographically secure PRNG specified in the W3C Web Crypto standard and backed by the operating system entropy pool — getrandom(2) on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS. NIST SP 800-90A compliant drivers feed those primitives. The same API is used by libraries like @noble/hashes and tweetnacl-js for key generation. For passwords, the only way to do better is to use a hardware security module, and HSM key generation is overkill for anything short of root CA certificates.

Should I turn off the ambiguous-character filter?

Depends on how the password will be consumed. If a human will type it from a printed page or screenshot — field tech reading a Wi-Fi password, support engineer reciting it over the phone — keep ambiguous characters excluded so 0 and O, 1 and l and I cannot be confused. For machine-only secrets pasted directly into config files or password managers, leave it off; excluding five characters reduces the pool from 94 to 89 printable ASCII and costs you less than 0.1 bits per character, but removes any reason for a future teammate to mistype it.

Why does an 8-character password show as 'weak' even with symbols?

Because modern GPU clusters benchmark over 100 billion MD5 or NTLM guesses per second per GPU. A password of length 8 drawn from the full 94-character printable ASCII set has around 6 x 10^15 combinations, which falls to a single high-end GPU in roughly 16 hours. Our meter caps 'strong' at 16 characters with mixed classes because that is where offline attack time crosses the century mark even against fast hashes. For services using bcrypt or argon2 you can get away with less, but assume the worst-case hash.

Can I generate multiple passwords at once for a batch rotation?

The interface generates one at a time, but the generation itself is effectively free — clicking regenerate gives you a new password in under a millisecond because crypto.getRandomValues is a syscall away from the entropy pool. For batch rotations across 50+ secrets, script it instead: the same one-liner works in Node, Deno, or browser devtools — Array.from(crypto.getRandomValues(new Uint32Array(50))).map(n => n.toString(36).slice(-12)) gives you fifty alphanumeric passwords that you can pipe into a vault import file.

Are any passwords logged or cached anywhere?

No. Generation happens entirely inside the JavaScript VM tab you are looking at. There is no fetch call, no websocket, no telemetry beyond standard page analytics (which never sees DOM contents). The generated string exists in memory only until you navigate away or close the tab, at which point the V8 garbage collector reclaims it. We do not store it in localStorage, sessionStorage, IndexedDB, or a service worker cache. Browser devtools memory snapshots will show strings residually until GC, which is a browser limitation not a tool limitation.