Human-chosen passwords follow predictable shapes: a name, a birth year, a keyboard run, a trailing ! or 1. Attackers use dictionaries built from exactly those habits, so something that looks complicated is often far weaker than it appears.
This generator uses the browser's cryptographic randomness (crypto.getRandomValues) to produce passwords, memorable passphrases and API keys. It reports entropy in bits and an estimated brute-force time, so 'is this strong enough' becomes a number rather than a feeling.
How to use
- Pick the right mode — Password for web accounts, passphrase for things you must type by hand such as a laptop login or a vault master password, API key for values that live in server environment variables.
- Set the options — Length contributes the most to strength — aim for 20 characters or more where the site allows it. If you will transcribe the value by hand, enable exclude look-alikes to avoid confusing 0 with O and l with 1.
- Read the strength figures — Entropy above 75 bits reads as strong and above 100 as very strong. The numbers update as you change options.
- Copy into a password manager — Click any result to copy it. These values are meant to be stored in a manager, not memorised.
Frequently asked questions
Are generated passwords sent anywhere?
No. Generation happens entirely in your browser and nothing goes over the network.
Randomness comes from crypto.getRandomValues(), which draws on the operating system's secure entropy source. Unlike Math.random(), it is not derived from a predictable seed, so it is appropriate for cryptographic use. For your most sensitive credentials, a password manager's built-in generator or an offline tool remains the more conservative choice.
Are passphrases really as safe as random passwords?
They are, provided they are long enough.
amber-glacier-tundra-quartz is 27 characters and draws four words from a 200-word list, giving roughly 30 bits of entropy. Six words raises it to about 46 bits, and with the EFF's 7,776-word list six words reach about 77 bits.
The critical requirement is that the words be chosen randomly. Picking them from a song lyric or a proverb collapses the entropy, because the moment a human chooses, the randomness is gone.
The estimate says 'effectively forever' — am I safe?
That figure only models brute-forcing the password itself.
Real account compromises mostly happen another way: credential stuffing with passwords leaked from other sites, phishing, or malware on the device. No password is strong enough to survive being reused across sites.
So a strong generated password is the baseline; a different password per site and two-factor authentication are what actually protect the account.
What format should an API key use?
Base62 (letters and digits) is a safe default. It needs no escaping in URLs, headers or environment files, and double-clicking selects the whole token.
32 bytes (256 bits) is ample. A prefix such as sk_live_ tells you immediately which service and environment a leaked key belongs to — GitHub's secret scanning relies on exactly these prefix patterns to detect leaks automatically.
Concepts worth knowing
What entropy measures
Entropy expresses, in bits, how many guesses an attacker must make. It is length × log₂(alphabet size). Mixing upper case, lower case, digits and symbols gives roughly 95 possibilities per character, about 6.5 bits each, so 20 characters is around 130 bits.
Each additional bit doubles the search space, which is why adding length beats adding character classes. Sixteen lowercase characters are stronger than eight characters with symbols mixed in.
Hashing, salting and storage
Passwords must never be stored in plaintext. If you build services, use a deliberately slow hash — bcrypt, scrypt or Argon2 — with a unique salt per account.
General-purpose hashes like SHA-256 are unsuitable precisely because they are fast: a GPU can try billions per second, so a leaked database is cracked in bulk. Argon2 is designed to consume memory, which raises the cost of parallel attack dramatically. As a user you cannot tell whether a service did any of this, which is another reason never to reuse a password.
Rotation matters less than you were told
Forcing a password change every 90 days was conventional wisdom for decades. NIST's 2017 guidance reversed it, because forced rotation pushes people toward predictable variations: Password1! becomes Password2!.
The current recommendation is to generate one long random password, store it in a manager, and change it only when there is evidence of compromise. Adding two-factor authentication does far more for security than any rotation schedule.