Password Generator

Password Generator - Create Strong Random Passwords

A powerful password generator that creates cryptographically secure random passwords. Customize length, character types, and generate multiple passwords at once. Includes password strength meter to ensure your passwords are secure.

What makes a password strong in 2026?

Modern password strength is dominated by entropy — the logarithm of the search space an attacker must cover. NIST SP 800-63B (2024 revision) recommends a minimum of 8 characters but encourages 15 or more for any account that protects valuable data. Length matters more than complexity: a 20-character lowercase-only password has about 94 bits of entropy, far stronger than an 8-character mixed-case-digits-symbols password (~52 bits). The bigger factor is uniqueness — every account should have a distinct password, since the average breach exposes a credential that 65% of users reuse. Use a password manager (1Password, Bitwarden, KeePass) to generate and store random passwords per site, and protect the vault with a long passphrase plus hardware multi-factor authentication. Avoid mandatory periodic rotation (NIST removed that requirement) — it pushes users toward predictable variations.

How do random passwords compare to passphrases (diceware)?

Both can be strong if generated correctly. A random password of N characters from an alphabet of K symbols has N·log2(K) bits of entropy: 16 random characters from the 95-printable-ASCII alphabet give about 105 bits — beyond any feasible brute force. A diceware passphrase uses physical or cryptographic dice to pick words from a public list (the EFF long list has 7,776 = 6^5 words), giving log2(7776) ≈ 12.9 bits per word: 5 words give 64 bits (decent), 7 words give 90 bits (excellent), 10 words give 129 bits (overkill). Passphrases are easier to memorize, retype on phones, and dictate aloud, making them ideal for vault master passwords. Random character passwords are denser and better for sites with length caps. Critically, never invent your own words — use a verified random source.

What is entropy and how do I calculate it?

Information entropy (Shannon, 1948) measures unpredictability in bits. For a uniformly random password of length L chosen from an alphabet of size N, entropy = L × log2(N). A 12-character password from [a-zA-Z0-9] (62 chars) has 12 × log2(62) ≈ 71 bits. Each additional bit doubles the work for a brute-force attacker. Modern GPUs can compute ~100 billion (~37 bits) MD5 hashes per second per GPU, so an unsalted MD5-hashed 50-bit password falls in about a day on an 8-GPU rig. Properly salted bcrypt slows this to ~10,000 per second, pushing 70 bits to thousands of years. NIST recommends ≥80 bits for symmetric keys and equivalent strength for passwords protecting valuable accounts. Online "strength meters" that score based on visual heuristics ("add a symbol!") are largely theater — entropy from a true CSPRNG is what counts.

Why should I avoid common patterns like P@ssw0rd! or Summer2026?

Attackers do not guess randomly — they use mangled dictionary attacks based on leaked breach corpora (RockYou contained 14 million unique passwords; HaveIBeenPwned exposes 800+ million). Tools like Hashcat support rule files that perform every common substitution: P@ssw0rd, P@$$w0rd, Pa55w0rd, Pa$$word, etc., all hit within the first few million guesses. "Summer2026!" appears in essentially every modern wordlist with year permutations baked in. Names of family members, sports teams, pet names, and birthdates are similarly trivial because attackers cross-reference OSINT from social media. The defense is randomness from a CSPRNG (crypto.getRandomValues in browsers, secrets module in Python, /dev/urandom on Linux) — never patterns chosen by a human brain. Truly random passwords look unmemorable on purpose: that's why we use password managers.

Should passwords be stored hashed or encrypted on the server?

Always hashed, never encrypted or stored plaintext. Encryption is reversible — anyone with the key can decrypt all passwords, so a single key leak compromises every account. Hashing is one-way: even the server cannot recover the password from the stored hash. Use a modern adaptive password hashing function: Argon2id is the OWASP and IETF (RFC 9106) recommendation since 2015 as the winner of the Password Hashing Competition, with bcrypt and scrypt as acceptable legacy choices. PBKDF2-HMAC-SHA256 with ≥600,000 iterations is required for FIPS-compliant systems. Each password must use a unique random 16-byte salt to defeat rainbow tables. Plain SHA-256 or MD5 are NOT acceptable — they're orders of magnitude too fast. The 2012 LinkedIn breach exposed 117 million unsalted SHA-1 hashes; most were cracked within days.

Do I need 2FA if I have a strong password?

Yes — multi-factor authentication (MFA) defends against attacks that no password length can prevent: phishing, malware keyloggers, server-side breaches, and credential stuffing. NIST SP 800-63B classifies authenticators into three factors: something you know (password), something you have (security key, phone), something you are (fingerprint, face). True MFA requires at least two distinct factors. Order of preference: hardware security keys using FIDO2/WebAuthn (YubiKey, Titan) are phishing-resistant because they bind to the origin domain; TOTP apps (Authy, Google Authenticator) are good but vulnerable to real-time phishing proxies (Evilginx); SMS codes are the weakest (SIM-swap attacks) and discouraged by NIST since 2017. Push-based MFA (Microsoft Authenticator) is suffering from "MFA fatigue" attacks where attackers spam approval prompts. Use a hardware key wherever supported.

What characters should I include and which should I avoid?

Maximize the alphabet to maximize entropy. Modern systems should accept all 95 printable ASCII characters (0x20-0x7E): letters, digits, and the symbols !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ plus space. NIST SP 800-63B explicitly requires accepting all printable ASCII and ideally Unicode. However, real-world systems often misbehave: some strip < > to prevent XSS (a sign of broken sanitization on the server), some break on quotes or backslashes due to SQL escaping bugs, some truncate at 8 or 16 characters (a sign they're using crypt(3)). For maximum compatibility, generate passwords from [A-Za-z0-9!@#$%^&*()-_=+?]. Avoid look-alike characters (O vs 0, l vs 1 vs I) only if humans must type the password from sight; otherwise the entropy loss is unnecessary. Sites that ban any character are creating insecurity, not preventing it.

How many bits of entropy does my generated password have?

This tool computes it for you and shows it live next to every result. Entropy in bits = L × log2(N), where L is the password length and N is the size of the alphabet actually used (visible as "Alphabet Size" in the readout — 26 for lowercase only, 62 for mixed letters + digits, up to ~95 with all printable ASCII; excluding ambiguous characters lowers N slightly). For example, 16 characters from a 95-symbol alphabet yield 16 × log2(95) ≈ 105 bits. The panel also estimates offline crack time assuming a fast GPU rig at roughly 100 billion guesses per second against a fast unsalted hash — a deliberately pessimistic, attacker-friendly assumption. Real systems using salted bcrypt or Argon2id are thousands to millions of times slower, so the displayed time is a conservative floor. NIST SP 800-63B–aligned guidance: under 28 bits is very weak, 28–50 weak, 50–70 medium, 70–100 strong, and 100+ bits is effectively uncrackable by brute force. Unlike a vague 0–100% meter, bits of entropy are the number security engineers actually cite in policy decisions.

How does password cracking actually work?

Modern attackers don't guess passwords against a live login form — that triggers rate limiting and account lockouts. Instead they steal the password hash database (via SQL injection, insider, backup leak), then crack offline on dedicated rigs. Hashcat and John the Ripper are the primary tools, accelerated by GPUs (an RTX 4090 does ~200 GH/s on MD5, ~16 KH/s on bcrypt cost=10). The attack pipeline: (1) wordlist attack with rockyou.txt and breach corpora, (2) rule-based mutations (add 1, capitalize, swap a→@), (3) mask attacks on common patterns (?u?l?l?l?l?l?l?d?d for capitalized 6-letter word + 2 digits), (4) hybrid attacks combining wordlist + mask, (5) pure brute force only for short passwords. A salted bcrypt password with 12+ bits of entropy beyond a dictionary base resists all stages. Length plus randomness wins; complexity rules don't.

Key Features

• Generate cryptographically secure random passwords
• Customizable password length (4-128 characters)
• Choose character types: uppercase, lowercase, numbers, symbols
• Exclude ambiguous characters option
• Bulk generation (1-50 passwords)
• Real entropy readout in bits with NIST-aligned verdict
• Estimated offline crack-time estimate
• Guarantees at least one character from every selected class
• Copy, download, or open passwords
• 100% client-side - passwords never leave your browser
• Uses crypto.getRandomValues() for true randomness
• No data sent to server
• Works offline
• Dark mode support
• Mobile-friendly