Password Generator
Generate strong random passwords and passphrases with a computed entropy readout — unbiased, cryptographically random, never transmitted.
Options
86 character alphabetPasswords
129 bits · Very strongGenerating…
Generated in your browser with crypto.getRandomValues, using rejection sampling so every character is equally likely. Nothing is transmitted, stored or logged — reloading the page produces an entirely new batch.
About the Password Generator
Generate random passwords or passphrases in your browser, with an entropy figure that is actually computed rather than a coloured bar guessing at your typing. Nothing is transmitted, and reloading the page throws every generated value away.
Entropy here means log2(alphabet ^ length) — a measurement of the generator, not of the string it produced. That distinction matters. A meter that scores a password you typed is really scoring how well its heuristics model your habits; it will happily call P@ssw0rd123! strong. Because these values come from a known random process, the strength can be stated exactly instead of estimated.
The randomness comes from crypto.getRandomValues via rejection sampling. The tempting one-liner — take a random byte, take it modulo the alphabet size — is subtly biased whenever the alphabet does not divide the range evenly, making some characters measurably more likely. Discarding the draws that fall in the uneven tail removes that skew entirely.
One honest caveat about passphrase mode: the built-in word list holds 188 words, which is 7.55 bits per word. The EFF's standard Diceware list has 7,776 words and carries 12.9 bits each, so an EFF six-word passphrase (77 bits) needs about ten words here to match. The word count is set high by default for exactly that reason, and the bits-per-word figure is shown so you can check the arithmetic yourself.
- Unbiased selection via rejection sampling over crypto.getRandomValues
- Length from 8 to 128 characters, with per-set toggles for a–z, A–Z, 0–9 and symbols
- Optional exclusion of look-alike characters (I l 1 O 0 o S 5 B 8 G 6 Z 2)
- Passphrase mode with a configurable separator and word count
- Computed entropy in bits plus an offline cracking estimate, generated in bulk up to 25 at a time
How to use it
- Choose Password for a random character string, or Passphrase for something you have to type by hand.
- Set the length. For a password stored in a manager, 20 characters over the full alphabet is about 129 bits and there is no reason to go shorter.
- Turn off symbols or enable Avoid look-alikes if the value has to survive a system that mangles punctuation or be read aloud.
- Check the entropy readout — anything under 40 bits is marked Weak and should not protect anything that matters.
- Copy the value straight into a password manager. Do not reuse it, and generate a fresh one per account.
Real-world use cases
Backend & DevOps engineers
Generate a random value for a CI/CD environment variable, a local .env secret, or a database seed credential — computed with a real CSPRNG rather than a value typed off the top of your head.
QA & test engineers
Produce fresh, unique test-account credentials for an end-to-end suite, so parallel test runs never collide on a shared hardcoded password.
Security engineers
Generate a properly sized HMAC or session secret with a stated entropy figure, rather than eyeballing whether a string looks random enough.
Platform & SRE teams
Create a one-off passphrase for a break-glass account or a shared bootstrap credential — memorable enough to read off a runbook, with the entropy math shown so the tradeoff is explicit.
Solo developers & indie hackers
Generate an API key placeholder or a local admin password for a side project without reaching for a password manager's browser extension for a value that will only ever live in a config file.
Examples
A 20-character password
length: 20, all four character sets
K7#vRq2mZ!tLp9wXd$3B
An 86-character alphabet at 20 characters is about 129 bits. That is beyond any brute-force attack that will ever be built, and it is the right default for anything stored in a manager.
The same length, digits only
length: 20, digits only
48170392648205719364
A 10-character alphabet gives 3.32 bits per character, so the same length yields only 66 bits. Length alone is not strength — the alphabet matters just as much.
Avoiding look-alikes
length: 16, no ambiguous characters
hnT7fVxq4KwEy3RA
No I, l, 1, O, 0, S, 5, B, 8, G, 6, Z or 2. Worth it for a value someone has to read off a screen or dictate over a call. It costs a few bits: the alphabet drops from 86 to 72.
A passphrase
8 words, hyphen separator
thistle-marble-quiver-oyster-lantern-cobalt-pewter-glacier
8 words × 7.55 bits ≈ 60 bits. Long to type, but far easier to remember and retype than a random string — which is what you want for a laptop login or a master password.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Password is rejected: "invalid characters" | The site imposes an undocumented symbol allowlist — a depressingly common restriction. | Untick Symbols and add a few characters of length instead. Losing symbols costs about 1.3 bits per character; adding four characters more than makes it back. |
| Password is silently truncated on login | The service stores a fixed-width column or hashes only the first n characters, so a long password appears to work at signup and fails later. | If a very long password fails but a shorter one works, cap the length for that site and note it in your manager. |
| Confusing a 0 for an O when typing it in | Most fonts render several character pairs near-identically, and console fonts are the worst offenders. | Enable Avoid look-alikes for any value you will type by hand, or use passphrase mode. |
| A strength meter calls a weak password strong | Meters score patterns, not randomness. Substitutions like P@ssw0rd are in every cracking dictionary and add almost nothing. | Judge by entropy of the generator, not by a bar. A random 12-character password beats a 20-character clever one. |
| Same password generated twice | In practice this does not happen — but reusing one value across accounts has the same effect as a collision. | Generate one per account. Credential-stuffing attacks exist precisely because reuse is common. |
Frequently asked questions
›Are the generated passwords sent anywhere?
No. Generation happens entirely in your browser using crypto.getRandomValues, the same CSPRNG the browser uses for TLS. Nothing is transmitted, stored, logged, or written to history — you can generate with your network disconnected and it works identically. Closing the page destroys every value.
›How many bits of entropy do I actually need?
For anything behind a rate-limited login, 60 bits is plenty. For a value that could be attacked offline — a password manager's master password, a disk encryption key, an API secret in a leaked database — aim for 80 or more. A 20-character password over the full alphabet gives about 129 bits, which is past the point of any further benefit.
›Is a passphrase safer than a password?
Not inherently — only if it carries enough entropy, which depends entirely on the size of the word list and the number of words drawn. Its real advantage is human: it can be memorised and typed correctly, so people choose long ones. Use a passphrase where you must type it from memory, and a long random string everywhere a manager fills it in for you.
›Why is your word list smaller than Diceware's?
It is a curated 188-word subset, worth 7.55 bits per word against the EFF list's 12.9. That is stated plainly next to the slider, and the entropy figure reflects it rather than quoting a Diceware number that would not apply. Because of it, you need roughly ten words here to match a six-word EFF passphrase.
›What does the cracking time estimate assume?
10^11 guesses per second against a fast hash such as unsalted SHA-256 on rented GPUs, and that half the keyspace is searched. That is the pessimistic offline scenario. An online login with rate limiting is many orders of magnitude slower, and a properly stored password using Argon2id or bcrypt is far slower still.
›Does "one of each" make a password stronger?
Slightly weaker, in fact — forcing a character from every set removes some possible outputs and shrinks the keyspace a little. It is on by default only because so many sites demand it. The entropy shown ignores the effect rather than claiming a benefit that is not there.
›Why does modulo bias matter?
A random byte holds 256 values. If your alphabet is 86 characters, 256 does not divide evenly by 86, so the first 84 characters would come up slightly more often than the rest. It is a small skew but a real one, and it is free to avoid: discard the draws that fall past the last whole multiple and try again.
›Is this suitable for generating a secret key or API token, not just a login password?
Yes — that is the more common developer use for a tool like this. A 32+ character value over the full alphabet, or a generated value in hex from the secret side of the hash generator, gives comfortably enough entropy for an HMAC key, a session secret or a local API token. The same crypto.getRandomValues source and rejection sampling apply regardless of what the value is used for.
Last updated