Strong Password Generator

What makes a password actually strong?

A "strong password" isn't about being hard to remember — it's about having enough entropy (randomness) that an attacker can't reasonably brute-force or guess it. Entropy is measured in bits: each bit doubles the number of possible passwords. A password with 60 bits of entropy has 2⁶⁰ ≈ 1.15 quintillion possible values; with current hardware, that takes ~6 years to crack on a single GPU. 80 bits is the modern minimum for high-value accounts; 100+ bits is overkill but cheap.

The two factors that determine entropy:

• Length — each additional character multiplies the search space. Length matters more than complexity.
• Character classes — lowercase letters, uppercase, digits, symbols. Each class added expands the pool.

Counterintuitively, a 16-character password from [a-z] alone (75 bits) is stronger than an 8-character password using all symbols (53 bits). Length wins. This is why modern guidance (NIST, OWASP, every password manager's defaults) emphasize longer over more complex.

How a secure password generator works

The crucial difference between a "real" password generator and a fake one is the random number source. There are two:

❌ Math.random() — DO NOT USE

JavaScript's Math.random() is a pseudorandom number generator (PRNG) seeded from system state. It's fast and predictable enough that a determined attacker who knows when a password was generated can narrow down possibilities dramatically. The Mersenne Twister algorithm used internally is well-known and not designed for cryptographic use. Many "free password generators" online use Math.random() — their output is technically random-looking but not safe.

✅ crypto.getRandomValues() — the right way

Every modern browser exposes a cryptographically secure RNG via the Web Crypto API. The OS provides random bytes from a hardware entropy source (CPU jitter, mouse movement, network packet timing). The result is unpredictable enough for cryptographic keys, SSL handshakes, and password generation.

// SAFE — cryptographically secure
function securePassword(length, chars) {
  const arr = new Uint32Array(length);
  crypto.getRandomValues(arr);
  return Array.from(arr, n => chars[n % chars.length]).join('');
}

// UNSAFE — never use Math.random() for passwords
function unsafePassword(length, chars) {
  return Array.from({length}, () =>
    chars[Math.floor(Math.random() * chars.length)]
  ).join('');
}

// Use the secure version
const pw = securePassword(20, 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*');

This password generator uses crypto.getRandomValues() exclusively. Every password you see is generated from cryptographically secure entropy.

Random passwords vs passphrases — diceware

For passwords humans need to type or remember (master password for a password manager, full-disk encryption phrase, SSH key passphrase), random characters are painful. The alternative: diceware passphrases — multiple random words from a curated list, joined with hyphens or spaces.

Random 16-char password:
  v5kJ$7@nQc9!xRf2

Diceware 6-word passphrase:
  correct-horse-battery-staple-mango-pier

Both have ~78 bits of entropy. The passphrase is far easier to type
on a phone, easier to remember, and survives in the user's head.

The classic EFF wordlist has 7,776 words. Each word adds log₂(7776) ≈ 12.9 bits of entropy. Six words = ~77 bits, eight words = ~103 bits. That's the math behind the famous xkcd "correct horse battery staple" comic.

Use random passwords for: account passwords stored in a password manager (you never type them).
Use passphrases for: master passwords, full-disk encryption, SSH keys, anything you'll type by hand.

What NIST 800-63B actually recommends (2026)

NIST Special Publication 800-63B is the authoritative US federal guidance on digital identity. The 2017 update (still current in 2026 with minor revisions) overturned decades of conventional password wisdom:

• ✅ Use long passwords (≥ 8 chars minimum, prefer 14+).
• ✅ Allow ALL printable ASCII characters AND Unicode. No artificial restrictions.
• ✅ Check passwords against breach databases (HaveIBeenPwned, etc.) and reject ones that have appeared.
• ✅ Use a password manager. NIST explicitly endorses this.
• ❌ DON'T require composition rules ("must include uppercase, number, symbol"). Users respond by adding !1 at the end, which doesn't help.
• ❌ DON'T require periodic password changes unless there's evidence of compromise. Forced rotation leads to weaker passwords (people pick patterns like Spring2026!).
• ❌ DON'T use SMS for 2FA. SIM-swap attacks made this a known weak link. Use TOTP authenticator apps or hardware keys (YubiKey).
• ❌ DON'T allow security questions as a password reset mechanism. Most answers are searchable on social media.

Common password mistakes — what actually leaks accounts

• Password reuse across sites — the #1 cause of compromised accounts. One breach exposes every reused account. Per Verizon's DBIR, credential stuffing (using leaked passwords against other sites) accounts for > 60% of web app breaches. Fix: unique password per site, stored in a password manager.
• "Strong" patterns that aren't. P@ssw0rd123!, Spring2026!, WelcomeJune! — all hit composition requirements but are in every password-cracking dictionary. Fix: let a generator produce truly random output.
• Rotating one base password by appending a counter or month. Attackers expect this.
• Using a memorable word + symbol substitution (l3tm3in!). These are in cracking dictionaries.
• Writing passwords in a Notes app, email, or shared spreadsheet. Use a real password manager.
• Reusing the master password for your password manager elsewhere. The master must be unique.
• SMS-based 2FA on important accounts. SIM-swap attacks are common. Use a TOTP app (Aegis, Authy, Bitwarden's built-in) or hardware key.
• Storing passwords as MD5 or plain SHA-256 server-side. Both are too fast — a leaked database is cracked in hours. Use bcrypt, argon2id, or scrypt.
• Pasting passwords into chat/Slack to share. Logs, sync indexes, backups all see the message. Use one-time secret sharing (1Password Send, Bitwarden Send, encrypted Wire message).

Generating secure passwords in 8 languages

JavaScript / browser

function generatePassword(length = 20) {
  const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*';
  const arr = new Uint32Array(length);
  crypto.getRandomValues(arr);
  return Array.from(arr, n => chars[n % chars.length]).join('');
}
generatePassword(24);  // 'k7Y!qXm2$Pn9ZcVfRbT4@uA8'

Node.js

import { randomBytes, randomInt } from 'node:crypto';

function generatePassword(length = 20) {
  const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*';
  let pw = '';
  for (let i = 0; i < length; i++) pw += chars[randomInt(chars.length)];
  return pw;
}

Python

import secrets
import string

def generate_password(length=20):
    chars = string.ascii_letters + string.digits + string.punctuation
    return ''.join(secrets.choice(chars) for _ in range(length))

# secrets module is the cryptographically secure choice (Python 3.6+)
# DO NOT use random.choice() for passwords
print(generate_password(24))

PHP

function generatePassword(int $length = 20): string {
    $chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*';
    $max = strlen($chars) - 1;
    $pw = '';
    for ($i = 0; $i < $length; $i++) {
        $pw .= $chars[random_int(0, $max)];
    }
    return $pw;
}
// random_int() is cryptographically secure (PHP 7+)

Go

import (
    "crypto/rand"
    "math/big"
)

func GeneratePassword(length int) (string, error) {
    chars := "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*"
    pw := make([]byte, length)
    for i := range pw {
        n, err := rand.Int(rand.Reader, big.NewInt(int64(len(chars))))
        if err != nil { return "", err }
        pw[i] = chars[n.Int64()]
    }
    return string(pw), nil
}

Rust

use rand::Rng;
use rand::distributions::Alphanumeric;

fn generate_password(length: usize) -> String {
    rand::thread_rng()
        .sample_iter(&Alphanumeric)
        .take(length)
        .map(char::from)
        .collect()
}
// thread_rng() is cryptographically secure (uses ChaCha20)

Bash / shell

# Method 1 — /dev/urandom (POSIX)
LC_ALL=C tr -dc 'A-Za-z0-9!@#$%^&*' < /dev/urandom | head -c 20; echo

# Method 2 — openssl (more portable)
openssl rand -base64 24 | tr -d '/+=' | head -c 20; echo

# Diceware passphrase (4 random words from system dictionary)
shuf -n 4 /usr/share/dict/words | tr '\n' '-' | sed 's/-$/\n/'

Java

import java.security.SecureRandom;

public static String generatePassword(int length) {
    String chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*";
    SecureRandom rng = new SecureRandom();
    StringBuilder sb = new StringBuilder(length);
    for (int i = 0; i < length; i++) sb.append(chars.charAt(rng.nextInt(chars.length())));
    return sb.toString();
}
// SecureRandom is the JCA-blessed cryptographic RNG

What to do with passwords once generated

1. Store in a password manager (mandatory in 2026)

You will not remember 200 unique 20-character passwords. A password manager handles generation, storage, autofill, and breach monitoring. Top choices in 2026:

• Bitwarden — open-source, free tier, self-hostable. Industry standard.
• 1Password — best UX, family/team plans, Passkeys-first.
• KeePassXC — fully offline, open-source, plain-file storage. Best for security-paranoid users.
• iCloud Keychain / Google Password Manager — built-in, free, syncs to your devices. Convenient but ecosystem-locked.

2. Pair with multi-factor authentication (MFA)

A strong password isn't enough alone. Add MFA on every account that supports it. The hierarchy of MFA strength:

1. Hardware keys (FIDO2/WebAuthn) — YubiKey, Google Titan. Phishing-proof. The gold standard.
2. Passkeys — phishing-proof, biometric-gated. Replace passwords entirely on supported sites.
3. TOTP authenticator apps — Aegis, Authy, Bitwarden, 1Password. Time-based codes, offline-capable.
4. Push-based MFA — Duo, Microsoft Authenticator. Convenient but vulnerable to "MFA fatigue" attacks.
5. SMS — better than nothing, but vulnerable to SIM-swap attacks. Use only as a last resort.

3. Check breach databases

After generating, verify the password isn't in known breach corpora. HaveIBeenPwned's password API uses k-anonymity (only the first 5 chars of the SHA-1 hash leave your machine), making it safe to query. Most password managers (Bitwarden, 1Password) integrate this check automatically. To compute the SHA-1 prefix yourself for a manual lookup, drop the password into the hash generator — it stays client-side and the first 5 hex chars are all you need.

16-character random password — how long does it take to crack in 2026?

A 16-character password drawn from the full ASCII printable set (~95 characters) has roughly 105 bits of entropy. At 2026 GPU rates of ~150 billion SHA-256 hashes per second per RTX 5090, brute-force takes on the order of 10²² years — vastly longer than the age of the universe. The same length restricted to lowercase letters only (26 chars) drops to ~75 bits, still uncrackable for any realistic adversary. Length is the dominant variable; character-class rules add far less entropy than people think. NIST 800-63B explicitly drops the old "must contain uppercase + symbol" requirements for this reason. To match a generated password against an intentionally slow KDF before storage, see why bcrypt and Argon2id replace SHA-256 in the hash generator guide.

Generating service tokens, AWS root credentials, and SSH passphrases

Different secrets need different lengths. Use this matrix: human-typeable account passwords 16–20 chars; cloud root and SSH passphrases 24–32 chars (usually pasted from a manager, not typed); API keys, OAuth client secrets, and Stripe-style tokens 32–64 chars (machine-only). For machine-only secrets, prefer the UUID v4 generator when you need a guaranteed-unique opaque identifier, and the JWT generator when the token must carry signed claims (user id, expiry, scope). Generated passwords go in the secret store; never in environment files committed to Git.

Password manager import — Bitwarden, 1Password, KeePassXC CSV format

To bulk-load generated passwords into a password manager, save the batch output above as a CSV with the columns each manager expects:

• Bitwarden: folder, favorite, type, name, notes, fields, login_uri, login_username, login_password, login_totp
• 1Password: Title, Website, Username, Password, OTPAuth, Notes (1Password 8 also accepts 1PUX export format)
• KeePassXC: Group, Title, Username, Password, URL, Notes

Generate a batch of 50 passwords with the count selector above, paste into a spreadsheet, fill in the Title and URL columns, then export as CSV and import. The CSV files contain plaintext passwords — delete them after import and empty the trash. Reformat noisy CSV exports with the JSON to CSV converter if the manager outputs JSON instead.

Best free password generator for 2026 — what to look for

"Free" doesn't mean equal. The differences that matter — and the ones that don't — when picking a generator in 2026:

The two columns to actually scrutinize are RNG source and logs your input. A generator that uses Math.random() instead of a CSPRNG is broken — outputs can be predicted from a few samples. A generator that POSTs your generated password to its own backend (for "show your password strength!" gimmicks) has logged it before you ever see it. Open the browser DevTools Network tab while generating; if anything goes out, walk away.

How do I generate a strong password without a website logging it?

Three signals tell you a generator is genuinely client-side: (1) opening DevTools → Network shows zero requests when you click "Generate"; (2) the page works with your wifi turned off (cached static HTML still generates); (3) the source code references crypto.getRandomValues() or SecureRandom in plain view, not behind an API call. The generator on this page passes all three — view-source any time and search for "crypto.getRandomValues". If you want zero trust at all, run the page once with the network blocked, save the page locally (Ctrl/Cmd+S → "Webpage, complete"), and open it from your filesystem next time. The randomness is just as strong because crypto.getRandomValues() uses your OS entropy pool, not the network.

What's the best password generator that works offline?

For full offline workflow, three options each suited to a different threat model:

• This page, saved locally. Save the HTML once, open from disk, generate as many passwords as you need. Zero network. Fine for most users.
• KeePassXC desktop. Native app, no browser, generator and vault in one binary. Best when you also want offline credential storage.
• Command line: openssl rand -base64 24 or head -c 32 /dev/urandom | base64 on Linux/macOS, [Convert]::ToBase64String((1..24 | %{Get-Random -Min 0 -Max 256})) on PowerShell. Reads from the OS entropy pool directly. Useful for scripting password rotations across many servers.

Don't roll your own with Math.random, language-builtin random modules (Python's random is not cryptographic — use secrets), or shell $RANDOM. All three are predictable.

LastPass password generator alternative — 4 reasons users switched after the 2022 breach

Following the August 2022 LastPass disclosure (later expanded in December 2022 to confirm encrypted vault data was exfiltrated), traffic to alternative generators and managers spiked across every analytics tracker. The four reasons users gave for switching:

1. Closed source. LastPass's encryption and PBKDF2 iteration counts couldn't be independently audited. Open-source alternatives (Bitwarden, KeePassXC) ship code that researchers verify line-by-line.
2. Insufficient PBKDF2 iterations on legacy vaults. Pre-2018 LastPass vaults shipped with 5,000 PBKDF2 iterations — far below the OWASP-recommended 600,000 for SHA-256 in 2023. After the breach, those vaults were brute-forceable on commodity GPUs.
3. Server-side dependency for generation. Even the "client-side" generator triggered analytics events. A page that pings a server every time you generate has, at minimum, told the server you used the feature.
4. Free tier restrictions. The August 2021 free-tier change (one device class only) had already pushed users toward Bitwarden's truly-free tier. The breach was the second push.

This page is the simplest possible alternative for the generator portion: open-source-style static HTML, browser-only, no account, no logging. For full vault management with sync, Bitwarden's free tier is the standard recommendation in 2026. Pair generation here with the hash generator (when you need to verify Argon2id/bcrypt parameters) and the UUID generator (when the secret needs to be a guaranteed-unique identifier rather than a typeable password).

Password generator best practices for 2026

• Use 16 chars minimum, 20+ for high-value accounts. Length matters more than complexity.
• Always include all four character classes unless the target system rejects them. Disabling symbols halves entropy per char.
• Never use Math.random(). If a tool doesn't explicitly mention crypto.getRandomValues(), SecureRandom, secrets.choice, or /dev/urandom, walk away.
• Generate fresh passwords for every account. Reuse is the single biggest preventable security risk.
• Use a real password manager, not your browser's basic password store, not a spreadsheet, not a Notes file.
• Enable MFA wherever available, with hardware keys or TOTP — not SMS.
• For master passwords, use diceware — a memorable 6-word passphrase has ~77 bits of entropy and you can actually type it on a phone.
• Don't roll your own password hash on the server. Use bcrypt, argon2id, or scrypt. SHA-256 alone is too fast for password storage.
• Pin password length, not "complexity." Composition rules push users toward predictable patterns. NIST 800-63B explicitly discourages them.
• Don't paste passwords in URLs, chat, or logs. They get archived everywhere. Use one-time-secret sharing tools.