Password Generator

What this password generator does, and what it deliberately does not do

This is a password generator that samples characters — or whole words — uniformly at random and shows you the result. It does two things well: it removes you from the selection process, and it tells you honestly how much unpredictability the result contains. It does not rate your password out of five, it does not promise that the result cannot be cracked, and it does not print a crack time. Those three features are the most common ones on pages like this and all three are misleading.

The reason for the caution is that password strength is not a property of a string. It is a property of the process that produced the string, combined with facts about the defender that you cannot see. Two identical twenty-character strings can be worlds apart in real safety: one drawn from a uniform random source, one assembled by a person who thought it looked random. The generator below is only useful because it takes your judgement out of the loop entirely.

How the randomness works

Every character and every word here comes from crypto.getRandomValues, part of the Web Crypto API. The specification requires it to draw from the platform's cryptographically secure random source — the same pool that seeds TLS session keys. Nothing on this page calls Math.random, and that omission is deliberate rather than stylistic.

Math.random is a fast pseudo-random generator built for shuffling animations and picking sample data. In V8 it is an xorshift128+ generator whose entire state is 128 bits, and it is well established that observing a short run of consecutive outputs is enough to recover that state and then predict every subsequent value — and, because the algorithm is reversible, recover earlier ones too. It also generates numbers in batches and hands them out in an order that has surprised people writing security code. None of that matters for a card game. All of it matters for something that guards an account.

There is a second, subtler trap that this tool also avoids: modulo bias. The naive way to pick one of 62 characters is to take a random byte and use the remainder after dividing by 62. But 256 is not a multiple of 62, so the first few characters of the alphabet come up slightly more often than the rest. The bias is small, and it is also completely avoidable, so this generator uses rejection sampling — it draws a 32-bit value, discards it if it falls in the uneven tail of the range, and draws again. The result is a genuinely uniform distribution over the alphabet you selected.

Reading the entropy number honestly

The readout above the output shows entropy in bits. It is computed the only way it can be computed: the base-2 logarithm of the alphabet size, multiplied by the length. Twenty characters from a 94-symbol alphabet is about 131 bits. Six words from a 2048-word list is exactly 66 bits, because 2048 is 2¹¹.

Here is what that number does tell you. It is the log of the number of candidates an attacker would have to work through if they knew everything about how the password was made — the alphabet, the length, the tool — and knew nothing about the value itself. That is the right threat model, because in the real world the attacker usually does know your generation scheme. Assuming otherwise is security by obscurity.

Here is what it does not tell you, and this part matters more.

• It is not a time. Converting bits into years requires guesses per second, and that number spans something like twelve orders of magnitude depending on circumstances entirely outside your control. See the section below.
• It assumes the generator is sound. Entropy is a claim about a process. If the random source were broken, the arithmetic would be unchanged and the password would be worthless.
• It says nothing about the rest of the attack surface. A 131-bit password that you paste into a phishing page is a 0-bit password. Most accounts are not lost to brute force; they are lost to reuse, phishing, malware and support-desk social engineering.
• It does not survive editing. If you generate a value and then change a couple of characters to something memorable, the number above no longer describes what you are holding.

Why there is no crack-time estimate here

Ask three security engineers how long it takes to crack a given password and you will get three ranges spanning several orders of magnitude, because the honest answer is a function of at least four unknowns.

So instead of a number, here is a rule of thumb with the uncertainty left visible: anything below roughly 50 bits should be considered attackable by a motivated adversary with a stolen hash file, 80 bits is a comfortable target for an account password, and beyond about 128 bits the password has stopped being the weakest part of the system by a very wide margin. Those thresholds are judgement calls, not physics.

Length beats complexity

Adding a character multiplies the number of candidates by the size of the alphabet. Adding a character class only widens the alphabet, once. That asymmetry is why the traditional advice — one uppercase, one digit, one symbol — is mostly theatre, and why modern guidance including NIST's digital identity guidelines has moved away from mandatory composition rules and toward length plus a check against known-breached passwords.

Going from 62 characters to 94 buys 0.6 bits per character. Going from 16 characters to 20 at the 62-character alphabet buys almost 24 bits. Both are free to the generator; only one of them is free to you, because composition rules are what push people toward Password1! — a string that satisfies every rule and is in every cracking dictionary. Turn the symbol class on when the site allows it, but do not trade length for it.

The exclude ambiguous characters option exists for the case where a password will be read off a screen and typed by a human, or dictated over a phone. It removes the characters people confuse: capital I, lowercase l and the digit 1; capital O, lowercase o and the digit 0; and the quote-like characters that vary between fonts. It shrinks the alphabet slightly, so the entropy readout drops. If the password is going straight into a manager and will never be read aloud, leave it off.

Passphrases and the Diceware idea

Passphrase mode joins randomly chosen words with a separator. The idea comes from Diceware, published by Arnold Reinhold in 1995: number a word list, roll physical dice to index into it, and repeat. The point was never that words are inherently strong — it was that dice are a random source a human can audit, and that the resulting phrase is possible to remember and to type on a phone keyboard.

The arithmetic is unambiguous. This tool's list contains 2048 words, so each randomly chosen word is worth exactly log₂(2048) = 11 bits. Five words is 55 bits, six is 66, eight is 88. The original Diceware list has 7776 entries — five dice rolls — and is worth 12.9 bits per word. The EFF's long list is also 7776 words, chosen to be easier to type and spell. Whichever list you use, the entropy is words × log₂(list size), and nothing else about the phrase changes it.

Three things people get wrong about passphrases:

• Choosing the words yourself destroys it. "correct horse battery staple" is famous, and famous strings are in wordlists. If a generated word is one you dislike, generate a whole new phrase rather than swapping that word — swapping is a human choice, and human choices are predictable.
• The separator is not a secret. Assume the attacker knows you used hyphens, knows the list, and knows the word count. Your security is the 11 bits per word, nothing more.
• Capitalising and appending a digit is almost worthless. Capitalising the first letter of each word is a fixed rule, so it adds zero bits once the attacker assumes it. A single trailing digit adds 3.3 bits. One extra word adds 11. The options are in the tool because password policies demand mixed case and a number, not because they help.

Passphrases earn their place in exactly the situations where a manager cannot help: the master password for the manager itself, a full-disk encryption passphrase, an SSH key passphrase, a recovery phrase you may have to type on a television remote. For the two hundred website logins behind the manager, a random twenty-character string you never see is strictly better.

The thing that actually protects your accounts

Reuse is the real risk. Credential stuffing — taking username and password pairs from one breach and replaying them everywhere else — is the mechanism behind an enormous share of account takeovers, and it works no matter how strong the password was, because the attacker is not guessing. A 128-bit password used on two sites is exactly as compromised as a weak one once either site leaks.

Which means the honest recommendation on a page like this is: use a password manager. Not as an upsell, and not to any particular product — the built-in managers in current browsers and operating systems are far better than reuse, and dedicated managers are better still. A manager makes every password unique and long by default, which is the property that actually matters, and it removes the human step that generators cannot fix. This generator is for the small set of secrets a manager cannot hold: its own master password, and machine credentials that belong in a secrets store rather than a vault.

Two more habits worth more than any amount of extra entropy. Turn on multi-factor authentication, and prefer an authenticator app or a hardware security key over SMS, because SIM swapping is routine. And check your addresses against a breach notification service; a password that has appeared in a public corpus is compromised regardless of its length, which is exactly why breach checking has replaced composition rules in modern guidance.

Credentials in developer workflows

If you landed here while building something rather than signing up for something, a few notes specific to that context. Generated secrets used as API credentials should be long random strings, not passphrases — nobody types them, so readability buys nothing. They should never be committed, never pasted into a bug report, and never left in a URL: query strings end up in server logs, browser history and referrer headers, which is why our own tester redacts them before writing request history, as described on the privacy page.

Do not store user passwords with any of the fast hashes from our hash generator — SHA-256 is the right tool for integrity and the wrong tool for passwords, because being fast is its whole purpose. Use Argon2id, scrypt or bcrypt with a deliberately expensive work factor. For token-based auth, a random secret in an Authorization: Bearer header beats a password on every request, and understanding how OAuth and JWT differ will usually tell you whether you needed a password at all. When a credential fails, the status code is informative: read 401 Unauthorized as "we do not know who you are" and 403 Forbidden as "we know, and no".

Frequently asked questions

Related tools and reference