Secure Password Generator: The Complete 2026 Guide

A password generator solves exactly one problem, and solves it completely: humans cannot produce randomness. Most of what people believe about the rest — rotate every 90 days, force a symbol and a digit, twelve characters is plenty — is obsolete or was never true. NIST rewrote the rules in SP 800-63B Rev. 4, and most advice online still repeats the version it replaced.

This guide covers what actually makes a password hard to guess, how entropy is calculated with the arithmetic shown, how to tell a safe generator from a dangerous one, and where passkeys are replacing passwords outright. Generate one with the password generator, then read on to understand what the output is worth.

What NIST actually requires in 2026

NIST Special Publication 800-63B Rev. 4 is the reference US federal agencies follow and from which most enterprise policy derives. Its requirements for what it calls "memorized secrets" contradict nearly every list of password tips written before 2017 and still circulating today.

Advice you have probably read	SP 800-63B Rev. 4 requirement
Change your password every 90 days	Verifiers SHALL NOT require periodic password changes. Force a change only on evidence of compromise.
Must mix uppercase, lowercase, a digit and a symbol	Verifiers SHALL NOT impose composition rules requiring mixtures of character types.
Eight characters is the minimum	Minimum 15 characters when the password is the only factor; 8 when it is one factor inside multi-factor authentication.
Sites may cap length at 16 or 20 characters	Verifiers SHOULD permit a maximum length of at least 64 characters.
Only letters, digits and a short symbol list are allowed	Should accept all printing ASCII characters and the space, plus Unicode, each code point counted as one character.
Disable paste on password fields "for security"	Verifiers SHOULD permit the paste function, precisely so password managers work.
Password hints and security questions help recovery	Hints accessible to unauthenticated users are prohibited, and verifiers SHALL NOT prompt for knowledge-based authentication.
Complexity alone makes a password safe	Candidates SHALL be compared against a blocklist of commonly used, expected and breached passwords.

Read that table as one instruction: length and unpredictability are the whole game. A 20-character all-lowercase string beats a 10-character one bristling with symbols. Composition rules were dropped because they push people toward predictable substitutions — capital first, digit and symbol last — which shrinks the search space instead of expanding it.

Entropy, and how it is actually calculated

Password strength is measured in bits of entropy. For a password drawn uniformly at random from an alphabet of N characters at length L, the calculation is:

entropy (bits) = L × log2(N)

That formula is valid only when every character is chosen independently and uniformly — which is exactly what a generator does and exactly what a person does not. Each additional bit doubles the guesses required. Here is the arithmetic worked out:

Length	Lowercase only (26)	Mixed-case letters (52)	Alphanumeric (62)	Printable ASCII + space (95)
8 characters	37.6 bits	45.6 bits	47.6 bits	52.6 bits
12 characters	56.4 bits	68.4 bits	71.5 bits	78.8 bits
15 characters	70.5 bits	85.5 bits	89.3 bits	98.5 bits
16 characters	75.2 bits	91.2 bits	95.3 bits	105.1 bits
20 characters	94.0 bits	114.0 bits	119.1 bits	131.4 bits

Notice how little the character set contributes next to length. At 16 characters, moving from alphanumeric to full ASCII buys about 10 bits; moving from 16 to 20 characters in the same alphabet buys about 24. That is why "add a symbol" is weak advice and "add four characters" is strong advice.

Turning bits into guessing time

An attacker expects to succeed after searching about half the space, so average guesses are roughly 2^(bits-1). Converting that to elapsed time needs an assumed guess rate, and the rate depends on how the site stored the password. The figures below are arithmetic at three stated rates, not measurements of particular hardware.

Secret	Entropy	10^4 guesses/s (throttled online)	10^9 guesses/s (offline, slow hash)	10^12 guesses/s (offline, fast hash)
8 chars, full ASCII	52.6 bits	~10,500 years	~38 days	~55 minutes
12 chars, full ASCII	78.8 bits	~8.6 × 10^11 years	~8.6 million years	~8,600 years
15 chars, full ASCII	98.5 bits	effectively never	~7.3 × 10^12 years	~7.3 billion years
20 chars, full ASCII	131.4 bits	effectively never	effectively never	~5.7 × 10^19 years
4-word passphrase	51.7 bits	~5,800 years	~21 days	~30 minutes
6-word passphrase	77.5 bits	~3.5 × 10^11 years	~3.5 million years	~3,500 years
7-word passphrase	90.5 bits	effectively never	~2.7 × 10^10 years	~27 million years

The lesson is in the columns, not the rows. The same 8-character password is unbreakable against a login form and falls in under an hour offline. You do not choose the column — the site does, through its storage. Pick lengths that survive the worst one.

Why "random-looking" human passwords are weak

Take Summer2024! — eleven characters, upper and lower case, a digit run, a symbol. It satisfies every composition rule ever written. Apply the formula naively and you get 72.3 bits, which the table above calls unbreakable.

It is not, because the formula does not apply. The password was never sampled uniformly from 95^11 possibilities. It came from a tiny structured set: a common word, capitalised, a recent year, one of a handful of terminal symbols. A rule enumerating every dictionary word against every plausible year and symbol covers a few million candidates — roughly 21 bits, not 72. It falls instantly at any rate.

That is the gap between character-set entropy (what the string looks like) and guessing entropy (how it was chosen). Attackers model how people choose. Leetspeak substitutions, keyboard walks like qwerty and 1qaz2wsx, name-plus-birthdate and a trailing exclamation mark are in every serious cracking ruleset. A meter such as the password strength test is useful precisely because it estimates guessing entropy from patterns rather than counting character classes.

How a real generator produces randomness

A generator is only as good as its randomness source. Two things matter.

It must use a cryptographically secure pseudorandom number generator. In a browser that means the Web Crypto API's getRandomValues, seeded from the operating system entropy pool. The everyday alternative, JavaScript's Math.random, is fast but predictable: observing enough output lets an attacker reconstruct its internal state and reproduce every "random" password it will ever emit. A general-purpose random number generator is fine for picking a raffle winner and unfit for picking a credential.

It must not bias the mapping from random bytes to characters. Taking a random byte modulo the alphabet size makes the first few characters slightly more likely, quietly shaving entropy off every password. Correct implementations reject out-of-range values and draw again.

Client-side generation: the one thing to check

The safe design is simple to state: the password is created in your browser by your own device, is never transmitted, and is never stored by the site. A server-side generator builds the password on a remote machine and sends it back over the wire, which means someone else's server saw your credential, and its logs and backups may still hold it.

You do not need to take a vendor's word for this. Check it yourself:

1. Confirm the page is served over HTTPS. Necessary but not sufficient — it protects the page's code in transit, not your password afterwards.
2. Open developer tools and select the Network tab before you click generate.
3. Generate a password and watch the request list. A client-side generator produces zero new network requests. If one fires the moment you click, inspect its payload.
4. Disconnect from the network and click generate again. A genuine client-side tool keeps working offline. A server-side one cannot.
5. Refuse any generator that asks for an email address, a name or any account detail. A generator has no legitimate use for personal data; being asked for it is the signal to leave.

This reframes a warning that ran through the older articles here — that a generator's "password database" might be breached, so prefer generators with "strong encryption." A correctly built generator has no database and nothing to encrypt, because your password never reaches it. The offline-versus-online framing misses the same point: what matters is whether the secret leaves your machine.

Passphrases: the other correct answer

A passphrase is several words chosen at random from a known list — not a sentence you invented. The standard EFF and Diceware long word lists hold 7,776 words (6^5, so five dice rolls select one), giving log2(7,776) = 12.925 bits per word.

Words	Entropy	Comparable to	Suitable for
4 words	51.7 bits	an 8-character ASCII password	Nothing important
5 words	64.6 bits	a 10-character ASCII password	Low-value accounts only
6 words	77.5 bits	a 12-character ASCII password	A reasonable floor for a vault master password
7 words	90.5 bits	a 14-character ASCII password	Master passwords, disk encryption
8 words	103.4 bits	a 16-character ASCII password	High-value, long-lived secrets

The trade is transparent: a passphrase needs more characters for the same entropy, and buys memorability with that length. So it is right for the few secrets you type from memory — a vault master password, a disk encryption key, a device login — and wrong for the hundreds of site passwords you never type. Those should be maximum-length random strings your manager fills.

The critical rule: the words must be picked by dice or a CSPRNG, not by you. A phrase you compose yourself has the same defect as Summer2024! — it follows the grammar and vocabulary of your own mind, a far smaller space than 7,776^6.

Checking a password against breach data

Entropy tells you whether a password can be guessed. It says nothing about whether it has already been published. A perfectly random 16-character string that leaked three years ago has no value left, and NIST requires verifiers to screen candidates against such a blocklist.

The standard mechanism is the Have I Been Pwned range API, which uses k-anonymity. Your client hashes the password with SHA-1, sends only the first five characters of that hash, and receives the suffixes of every hash sharing that prefix — around 800 of them — with a count of how often each appeared in breach corpora. The comparison happens locally, so the service never sees your password or its full hash. A pwned password checker is worth running against every credential you reused before adopting a manager, and the SHA generator produces the same SHA-1 digest the protocol is built on if you want to see the construction. The API also offers an NTLM mode, which is why an MD4 generator remains relevant: NTLM hashes are unsalted MD4, and Windows domain dumps are a major source of breach corpora.

Credential stuffing is the attack this defends against. Attackers replay username and password pairs from one breach against hundreds of other services, and the reused accounts fall. Downstream, those compromised accounts feed application fraud, synthetic identity creation and other online fraud. Unique passwords break the chain — not complexity, not rotation.

How the site should be storing your password

You control length and uniqueness; the service controls everything after you submit. NIST requires passwords to be salted and hashed with an approved scheme, using a salt of at least 32 bits and a cost factor as high as performance allows, and recommends an additional keyed hashing step with a secret stored separately from the hashes, so a stolen database alone is not enough.

Storage method	Built for password storage?	What it means for you
bcrypt, scrypt, Argon2, PBKDF2	Yes — deliberately slow, salted, tunable cost	A leaked database resists offline cracking; the "slow hash" column applies
Plain SHA-256 or SHA-1	No — built to be fast	A leak is cracked at the "fast hash" rate; only length saves you
MD5, MD4, MD2	No — fast and cryptographically broken	Treat any account stored this way as already compromised
Reversible encryption or plaintext	No	If a site can email you your existing password, it is not hashing it at all

If you build or audit software, a bcrypt generator produces and verifies correctly salted hashes at a chosen cost factor, and a general hash generator makes the speed gap obvious. The MD5 generator is worth one demonstration: the same input always yields the same unsalted digest, which is exactly why rainbow tables defeat it. Sessions issued after login are a separate exposure — a JWT decoder shows what a token asserts and when it expires, since a long-lived token can outlive a password change.

Password managers, passkeys and MFA

The manager is what makes the generator usable

A generator without a manager is a novelty. The workflow holds together only when the two combine: the generator creates a maximum-length random string, the manager stores it in an encrypted vault, and autofill enters it so you never see or type it. You memorise one thing — a six- or seven-word passphrase for the vault.

Autofill carries an underrated benefit: a manager fills credentials only on the domain they were saved for. Shown a convincing lookalike page, it silently declines — a free phishing warning.

Choose a manager on four criteria: an audited, published encryption design; a vault only you can decrypt; export in a portable format so you are never trapped; and support for every platform you use. Options run from cloud-synced commercial services to fully local open-source tools such as KeePass. Pricing and tiers change often, so check current terms with each vendor rather than any article's snapshot, including this one.

Passkeys and FIDO2 replace the password entirely

A passkey is not a password stored more cleverly. It is a public-private key pair. At registration your device generates the pair, sends the public key to the service and keeps the private key on the device. To sign in, the service sends a challenge; your device signs it with the private key and returns the signature. The private key is never transmitted, so a breach of the service leaks public keys, which are useless to an attacker.

Two points are widely misunderstood. First, your fingerprint or face is not the credential. Biometric data is used locally to unlock the private key and is never sent to the server — the same role a device PIN plays. Second, the signature is bound to the origin: the browser checks that the domain matches the one registered. A phishing site on a lookalike domain cannot obtain a valid signature even if you try to give it one. That origin binding, not the biometric, is what makes passkeys phishing-resistant.

Passkeys that sync across devices through a platform account are convenient and appropriate for consumer accounts. Note the trade: NIST treats syncable authenticators as unsuitable for its highest assurance level, AAL3, precisely because the private key can be copied between devices by the sync fabric.

MFA, and why SMS is a restricted authenticator

Until passkeys are universal, multi-factor authentication is the highest-value change you can make — above all on your email account, the reset path for everything else, and on the password manager itself.

Second factor	Phishing-resistant?	Notes
Security key or passkey (FIDO2, WebAuthn)	Yes — origin-bound	Strongest widely available option
Authenticator app (TOTP)	No	Codes are relayable in real time, but immune to SIM attacks
Push approval	No	Vulnerable to approval fatigue unless number-matching is enforced
SMS or voice call (PSTN)	No	Restricted under SP 800-63B Rev. 4 — better than nothing, worst of the list

NIST's designation of PSTN-delivered codes as restricted is a formal status, not a figure of speech. Verifiers are told to weigh risk indicators such as device swap, SIM change, number porting and other abnormal behaviour before sending a code, and they must keep alternative authenticator types available to every subscriber. NIST also says it may revise that status as the threat landscape evolves. Practically: enable SMS if it is the only option, and move to an app or a key as soon as one appears.

TOTP is worth understanding rather than treating as magic. The code is an HMAC of a shared secret and the current 30-second time step, truncated to six digits — you can reproduce the mechanism with an HMAC generator, and a TOTP generator lets you confirm a freshly enrolled seed produces the codes a service expects before you rely on it. Because the secret is shared, whoever holds it can generate codes — which is exactly why TOTP is not phishing-resistant and a passkey is.

Putting it into practice

Work through this once; maintenance afterwards is negligible.

1. Install a password manager and set its master passphrase to at least six randomly chosen words. Write it on paper and store it somewhere physically secure until it is memorised.
2. Turn on multi-factor authentication for the manager itself, using a security key or an authenticator app rather than SMS.
3. Secure your email account next. It controls password resets everywhere else, so it needs a unique generated password and the strongest second factor available.
4. Work down your accounts by value — banking, primary email, cloud storage, then the rest. Generate a fresh password at the longest length each site accepts and save it straight into the vault.
5. Set the generator's defaults sensibly: 20 characters or more where allowed, never below 15 for anything password-only. Enable "exclude ambiguous characters" only when you will read the password aloud or retype it by hand.
6. Register a passkey wherever it is offered, keeping the generated password in the vault as a fallback.
7. Screen your legacy passwords against breach data and replace every hit, along with every password you know is reused.
8. Stop scheduled rotation. Change a password on evidence of compromise, on a disclosed breach, or when someone who had access no longer should — not on a calendar.

What this guide retires

The pages this one replaces carried advice now contradicted by the standard. Dropped outright: mandatory 90-day, three-month and six-month rotation; forced character-class complexity as a requirement; 8 and 12 characters offered as sufficient minimums; the claim that a generator needs "strong encryption" or that its password database could be breached; the notion that offline generators are inherently safer than in-browser ones; generators building in mnemonic or keyboard patterns for memorability; and security questions and hints as legitimate recovery mechanisms. Unverifiable product pricing claims were removed rather than repeated.

Frequently asked questions

How long should my password actually be?

At least 15 characters for anything protected by a password alone — NIST's floor, not a suggestion. Use 20 or more wherever the site permits, since your manager does the typing. For a master passphrase you must recall, six or seven randomly chosen words.

Is it safe to generate a password on a website?

It is safe if the password is generated in your browser and never transmitted. Verify it: open developer tools, click generate, and confirm no network request fires — or go offline and check the tool still works. Anything that asks for personal details, or stops working without a connection, should be avoided.

Do I still need to change my passwords every 90 days?

No. SP 800-63B Rev. 4 states verifiers shall not require periodic changes. Scheduled rotation pushes people toward small predictable edits — appending a digit, incrementing a year — which weakens passwords rather than strengthening them. Change on evidence of compromise instead.

Are passphrases really as strong as random character strings?

Per character, no; per secret, they can be. Each word from a 7,776-word list contributes 12.925 bits, so a six-word passphrase is worth roughly a 12-character full-ASCII password. The words must be selected randomly — a phrase you compose yourself is far weaker than the arithmetic suggests.

What if a site rejects my generated password?

Length caps below 64 characters and bans on spaces or symbols both run against current guidance, but you still have to live with the site. Regenerate within its limits, keep the length as high as allowed, and give that account a second factor.

Do passkeys mean I can stop using a password manager?

Not yet. Coverage is incomplete, many services still keep a password fallback, and your manager remains where recovery codes and legacy credentials live. Adopt passkeys wherever offered and keep the vault running underneath.

Is a fingerprint or face scan a password?

No. Biometrics unlock a key that already lives on your device; the scan is never sent to the service and is not the credential. It is a local unlock gesture, functionally equivalent to a device PIN, wrapped around the private key that does the actual authenticating.

How do I check whether a password I already use has been exposed?

Run it through a breach checker built on the k-anonymity range API, which sends only the first five characters of the password's SHA-1 hash and compares the returned suffixes locally. If it appears in the corpus even once, replace it everywhere it was used, however strong it looks.