Password Generator & Strength Checker

What This Tool Does

This tool generates cryptographically random passwords using the Web Crypto API. All four generation modes pull randomness exclusively from crypto.getRandomValues, the browser-side interface to the operating system's CSPRNG. There is no fallback to Math.random(), no network call, and no persistent storage of generated material.

Four distinct generation modes cover the practical range of password needs:

• Random character mode - the default. Choose a length (8-128) and an alphabet built from any combination of lowercase letters, uppercase letters, digits, and symbols. Optional ambiguous-character exclusion removes 0, O, l, 1, and I for readability.
• Pronounceable mode - generates passwords that follow English phonotactic patterns using Markov-chain transition probabilities over consonant-vowel-consonant syllables. Sacrifices roughly 2 bits of entropy per character compared to fully random strings, but produces strings a human can actually pronounce and recall briefly.
• Diceware passphrase mode - draws words from the Electronic Frontier Foundation's 2016 long word list (7776 words). Each word contributes log2(7776) = 12.92 bits of entropy. A 5-word passphrase carries 64.6 bits; a 7-word passphrase carries 90.4 bits. Words are joined with hyphens by default; the separator is configurable.
• Pattern mode - generates strings matching a placeholder template (for example, Aaa-####-aaa produces three letters, four digits, three letters with explicit casing). Useful for legacy systems that enforce specific character-class positions, but understand that constraining the pattern reduces the keyspace.

The strength meter computes Shannon entropy as length x log2(alphabet_size) and translates that into a crack-time estimate assuming 10 billion guesses per second - representative of a modern GPU cluster attacking a fast hash function like NTLM. For slow hashes such as bcrypt or Argon2id, real crack times are many orders of magnitude longer; the displayed estimate is therefore a conservative lower bound.

Privacy guarantee. Open your browser's developer tools, switch to the Network tab, then click Generate. You will see zero outbound requests carrying password material. The page can run with the network entirely disconnected once it has loaded; randomness comes from your local machine. This is verifiable, not just claimed.

How to Use the Generator

The fastest workflow is to pick a generation mode that matches your use case, adjust the length or word count, and click Generate. Each option below maps to a concrete attack-model choice.

Step 1: Choose Your Mode

For passwords stored in a password manager and never re-typed, use random character mode with the full ASCII printable alphabet and 16-20 character length. For a master password that protects your password manager itself - typed from memory across phones, laptops, and shared kiosks - use Diceware passphrase mode with 6-7 words. For credentials that someone will read off a screen and type on a different device (Wi-Fi codes, temporary access codes), enable exclude ambiguous characters to remove the 0/O and 1/l/I visual collisions.

Step 2: Set Length and Alphabet

For random character mode, slide the length to 16 (the practical minimum for 2026) or higher. Tick the character classes you need. The strength meter updates live, showing both entropy in bits and an estimated crack time. For Diceware mode, pick a word count - 5 words for accounts, 7 for master passwords. For pattern mode, type a template using A (uppercase letter), a (lowercase letter), # (digit), and ! (symbol) placeholders.

Step 3: Generate Multiple at Once

The Number of Passwords field accepts values from 1 to 20. Generating a batch is useful for rotation events (replacing several service-account passwords) or for picking the most aesthetically usable result from a set. Each password in the batch is generated independently with its own fresh draw from the CSPRNG.

Step 4: Copy Without Leaving a Trail

Click any password to copy it. If your browser supports the modern Async Clipboard API, the copy happens directly through navigator.clipboard.writeText; older browsers fall back to a temporary off-screen text node. After pasting into the destination field, clear your clipboard explicitly if you are on a shared machine - some clipboard managers retain history for hours and a few synchronize clipboard contents across devices over the network.

Worked Example: 16-Character Random vs. 4-Word Diceware

The fastest way to internalize the entropy-vs-memorability trade-off is to compute both side by side for representative password shapes. The numbers below come from the standard Shannon entropy formula H = L x log2(N), where L is the length in symbols and N is the alphabet size.

Random 16-Character Password (Full Printable ASCII)

Full printable ASCII consists of 95 characters: 26 lowercase letters, 26 uppercase letters, 10 digits, and 33 symbol characters (the !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ set plus space, although most generators omit space). A 16-character password drawn from this alphabet carries:

H = 16 x log2(95) = 16 x 6.570 = 105.1 bits

At 10 billion guesses per second (a high-end GPU attacking NTLM, MD5, or unsalted SHA-1), the average time to exhaust half the keyspace is:

t = (2^105.1 / 2) / 10^10 seconds ~= 2.6 x 10^21 seconds ~= 8.2 x 10^13 years

That number is 82 trillion years - well past the heat death of the sun. Against a slow hash like bcrypt (which 2026 hardware attacks at roughly 100,000 guesses per second), the same password is even more robust. For password-manager-stored credentials, 16 characters of full printable ASCII is overkill in a way that costs nothing.

4-Word Diceware Passphrase (EFF Long List)

The EFF long word list contains exactly 7776 words (6^5, matching the original Reinhold dice-roll mapping). A 4-word passphrase carries:

H = 4 x log2(7776) = 4 x 12.925 = 51.7 bits

At 10 billion guesses per second, that gives:

t = (2^51.7 / 2) / 10^10 seconds ~= 188,000 seconds ~= 2.2 days

Against a fast hash, 4 words is not enough in 2026. Against bcrypt or Argon2id, the same passphrase would take roughly 6,000 years - perfectly acceptable for many threat models. This is why the choice between random string and passphrase is not the choice that matters most; the choice that matters most is whether the credential is hashed with a slow function (bcrypt, scrypt, Argon2id) or a fast one (MD5, SHA-1, NTLM). For online services you cannot control hash choice, so default to higher entropy. For 5-word Diceware the math gives 64.6 bits and 7-word gives 90.4 bits - 7 words is the master-password recommendation.

Visualizing the Trade-Off

The chart below plots entropy (bits) against crack time on a logarithmic axis for four representative shapes: a 4-word Diceware passphrase, a 6-word Diceware passphrase, a 12-character full-ASCII random password, and a 16-character full-ASCII random password. The shaded zones mark the qualitative strength tiers used by the live meter on this page.

What Both Numbers Tell You

Both passwords above are in the green zone for typical 2026 threat models, but they live at different points on the trade-off curve. The 16-character random password is roughly 53 bits stronger - an inconceivably large margin in absolute terms (2⁵³ times harder to crack). The 4-word passphrase is enormously easier to type from memory on a phone keyboard. For master passwords you re-type, the right answer is closer to 6-7 Diceware words (77-90 bits). For passwords your password manager autofills, the right answer is 16-24 random characters. Neither is universally correct; both are acceptable in different threat models.

Common Use Cases

The generator covers four distinct password classes, each with its own optimal configuration.

Password Manager Records

The dominant use case in 2026 is generating unique, high-entropy strings that your password manager (1Password, Bitwarden, KeePassXC, Apple Passwords, Proton Pass) stores and autofills. Configure 16-20 character random mode with the full alphabet enabled. Memorability does not matter because you will never type it. Entropy is essentially free at this length, so favor the upper end of the slider.

Password Manager Master Password

The master password is the one credential your password manager cannot store - you have to type it. Diceware passphrase mode with 6-7 words is the standard recommendation. The EFF list specifically chose words that are unambiguous to type on phone keyboards (no autocorrect collisions between adjacent entries) and that produce passphrases averaging 28-45 characters - long enough to resist offline attack against the vault's KDF.

API Keys and Service Tokens

For machine-to-machine credentials, prefer a structured token format over a freeform password. UUID v4 (122 bits of randomness, standardized format, easily indexed in databases) is the right primitive for opaque session tokens and API keys; see UUID Generator. If your service requires a string-like token, generate a 32-character random password from a URL-safe alphabet (alphanumerics plus - and _) to avoid percent-encoding issues. 32 characters of base-62 carries 190 bits of entropy - sufficient for any cryptographic purpose.

Database Root and Service Account Passwords

Root passwords for production databases (PostgreSQL postgres, MySQL root) should be 32+ character random strings stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). The generator's 32-128 length range covers this case. Service-account passwords used by application code rarely benefit from being typed by humans, so optimize for entropy and let your secrets manager handle distribution.

SSH Key Passphrases

The passphrase that encrypts your SSH private key on disk is a perfect Diceware target. You have to type it from memory each time you decrypt the key, but a long passphrase here is critical because the encrypted private key file is portable - it can leak. 5-7 word Diceware is standard. The Diceware passphrase encrypts the actual key material; it is not the key itself.

Encryption Key Derivation Seeds

For symmetric encryption (AES-256, ChaCha20-Poly1305), the actual key is 256 bits derived through a KDF (Argon2id, scrypt, PBKDF2) from a user-supplied passphrase. The passphrase you feed the KDF should carry at least as much entropy as the derived key, ideally more. A 7-word Diceware passphrase (90.4 bits) is below 256, but Argon2id's expensive computation makes brute-force against the passphrase orders of magnitude harder than the bit count suggests. For the actual encryption key, use random character mode at length 32+.

One-Time-Use Credentials

For temporary access codes that someone will read aloud or type once and discard, enable the ambiguous-character exclusion and pick 12-16 character length. The slight entropy loss is worth the eliminated misreading errors. Pattern mode is also useful here: a template like ####-####-#### produces 12 digits arranged in three groups of four - easy to dictate by phone, still 39.9 bits of entropy. After a few hours of monotonic-counter use, regenerate.

Edge Cases and Pitfalls

Generating a password is the easy part. The pitfalls below cause real-world weakening that is invisible until you check.

Math.random() is not cryptographically secure

Many tutorials and ad-hoc tools generate passwords with Math.random(). This tool does not. Math.random() is a pseudo-random number generator optimized for speed and statistical uniformity in simulations, not for cryptographic unpredictability. Browsers typically implement it with xorshift128+ or a similar small-state algorithm whose internal state can be recovered from a handful of observed outputs. An attacker who sees four or five values from Math.random() on the same page load can predict every past and future value. This generator uses crypto.getRandomValues exclusively - the browser's interface to the operating system CSPRNG. To verify, open DevTools and read the source: there is no Math.random() call in the generation path.

Excluding ambiguous characters reduces entropy ~1-5%

The default ambiguous exclusion set (0, O, l, 1, I) removes 5 characters from a 95-character alphabet. For a 16-character password, this drops entropy from 105.1 bits to 103.8 bits - a 1.2% loss. If you exclude all symbols too (a frequent legacy-system requirement), the alphabet shrinks to 62 characters and 16-char entropy drops to 95.3 bits - a 9.3% loss versus full ASCII. Compensate by adding 1-2 characters to the length when you apply restrictions.

Pattern mode is dangerous if over-prescribed

Pattern mode can quietly reduce entropy if your template constrains too many positions. Aaaaaa# generates a 7-character password with one uppercase letter (26 choices), 5 lowercase letters (26 each), and one digit (10 choices). Total keyspace: 26 x 26⁵ x 10 = 3.09 x 10⁹, or 31.5 bits of entropy - well below the 60-bit floor for online-attack resistance even against fast hashes. Use pattern mode only for legacy systems that enforce specific character-class positions, and lengthen the template until entropy crosses 80 bits.

Copy-paste history on shared machines

Most operating systems retain clipboard history. Windows 10+ has a clipboard history feature (Win+V); macOS has no built-in history but third-party clipboard managers (Alfred, Raycast, Maccy) commonly persist 50-500 entries. After pasting a generated password into your password manager, clear the clipboard explicitly - on Windows, copy a benign empty string; on macOS, run pbcopy < /dev/null. Better still, use a password manager that handles autofill through its own injection mechanism rather than the clipboard.

Screenshot-detection and over-the-shoulder threats

The generated passwords appear in plaintext in the page DOM. Browser screenshots, parental-control screen-recording software, accessibility-tool transcription, and shoulder-surfing are all viable attack vectors at the moment of display. The "show/hide" toggle on most password fields exists precisely for this. Generate in a private location where you control physical visibility.

Browser extension exposure

Browser extensions with activeTab or broader DOM permissions can read the generated password from the page. Audit your extensions, especially ad blockers and clipboard managers; even reputable extensions have been compromised through supply-chain attacks. For high-stakes credential generation, use a clean browser profile or an air-gapped environment.

Site-specific length and character restrictions

Many sites still enforce maximum password lengths of 16, 20, or 32 characters - even where their hash function (bcrypt) handles arbitrary length. Some forbid specific symbols. Generate in 24-character mode first; if the destination rejects it, shorten and regenerate rather than letting the truncation happen silently.

Behind the Scenes: CSPRNG, Diceware, and the Markov Pronounceable Mode

How crypto.getRandomValues Pulls From the OS Entropy Pool

When you click Generate, the tool calls crypto.getRandomValues(new Uint32Array(length)). The browser implementation routes this call to a kernel-level CSPRNG that draws from a continuously mixed entropy pool. The pool sources its raw entropy from hardware events whose timing has microsecond-level unpredictability: keyboard and mouse interrupt timing, disk I/O completion timing, network packet arrival jitter, and on modern CPUs the dedicated hardware random instructions (RDRAND on Intel/AMD, the ARM RNG instruction).

Each operating system implements the pool with a specific cryptographic primitive:

• Linux: /dev/urandom, which since kernel 5.18 uses ChaCha20 as the output stream cipher. Earlier kernels used a SHA-1 based construction.
• Windows: BCryptGenRandom, which calls the AES-CTR-DRBG construction specified in NIST SP 800-90A. The DRBG is reseeded periodically from the kernel's entropy pool.
• macOS, iOS, iPadOS, watchOS: SecRandomCopyBytes, implemented with the Fortuna construction (designed by Niels Ferguson and Bruce Schneier) over AES.
• FreeBSD, OpenBSD, NetBSD: arc4random family, built on ChaCha20 since 2013 (despite the legacy name referencing the deprecated RC4 cipher).

Browsers expose all of these uniformly through the Web Crypto API. The W3C Web Cryptography API specification requires that crypto.getRandomValues produce output indistinguishable from true randomness to any computationally bounded observer - in practice, every major browser meets this by delegating to the OS CSPRNG with no transformation.

Modulo Bias and How It Is Avoided

Naively mapping a 32-bit random integer onto a 95-character alphabet by computing value % 95 would introduce a tiny statistical bias - values 0 through 4 would be slightly more probable than values 5 through 94 because 2³² is not divisible by 95. The bias is negligible for typical password generation (the most-favored character is 1.000000022x more probable than the least-favored), but a fully correct implementation rejects values in the bias range and resamples. This generator uses sufficiently large draws (Uint32Array) that the modulo bias for any practical alphabet size stays below 10^-8 - far below detection threshold.

Diceware: Arnold Reinhold (1995) and the EFF List (2016)

Arnold Reinhold published the original Diceware method in 1995. The procedure is elegant: roll a physical 6-sided die five times to produce a 5-digit base-6 number (each die producing a digit 1-6, total 6⁵ = 7776 combinations), look up the corresponding word in a 7776-word list, repeat for each word in your passphrase. Each word contributes exactly log2(7776) = 12.92 bits of entropy. The randomness comes from physical dice, which avoids any concern about software CSPRNG correctness in the threat models Reinhold originally targeted.

The EFF published an improved 7776-word list in July 2016. The improvements:

• Distinct first 4 characters: no word is a prefix of another beyond the 4-character mark, so phone-keyboard autocomplete cannot confuse adjacent passphrase words.
• Length range 3-9 characters: short enough to be quick to type, long enough that frequency-analysis attacks gain no traction.
• No offensive or rare words: profanity and obscure technical terminology were removed.
• Common words preferred: words drawn from corpus frequency tables, weighted toward terms that English speakers actually know.

The EFF also published a "short" list of 1296 words (4 dice rolls per word, 10.34 bits each) for use when typing speed matters more than entropy density.

Markov-Chain Pronounceable Generation

Pronounceable mode generates strings that follow the phonotactic constraints of English: typical consonant-vowel-consonant patterns, no triple-consonant clusters that violate English phonology, vowel placement matching common syllable shapes. The generator uses a first-order Markov chain whose transition probabilities are computed from a corpus of common English words. State transitions favor consonant-vowel-consonant trigrams.

The entropy cost is significant: a fully random 10-character lowercase password carries 10 x log2(26) = 47.0 bits, but a pronounceable 10-character lowercase password carries approximately 10 x log2(8.5) = 30.5 bits because the Markov chain's average state branching factor is roughly 8.5 (versus 26 for fully random). Pronounceable mode is appropriate for temporary access codes you read aloud, but it should not be used as a long-term password without lengthening to compensate.

Strength Tier Cutoffs

The strength meter's tier cutoffs are:

• Weak: below 40 bits. Crackable in under a day at 10¹⁰ guesses/sec.
• Fair: 40-59 bits. Crackable in days to months against fast hashes; resistant for years against slow hashes.
• Good: 60-79 bits. The 2026 minimum for online accounts not protecting sensitive data.
• Strong: 80-99 bits. Resistant to all current attacks, including offline attacks on fast hashes.
• Very Strong: 100+ bits. Resistant to projected attacks through at least 2040 against any hash function.

These cutoffs are conservative. NIST SP 800-63B-r4 (2024) and the Open Web Application Security Project (OWASP) authentication cheat sheet endorse similar boundaries.

Comparison: This Tool vs. 1Password, Bitwarden, pwgen, openssl rand, KeePass

Most modern environments include at least one password generator. The table below compares the practical capabilities of each.

The practical takeaway: if you already use a password manager (1Password, Bitwarden, KeePassXC), use its generator and let it autofill. Round-tripping through this page works, but the manager's flow is more secure because the password never lands in your system clipboard. This page exists for the common cases where a manager is not at hand: generating a master password before you set up the manager, generating a Wi-Fi code to put on a printed label, or generating a one-time access credential to dictate over the phone.

For CLI workflows: openssl rand -base64 24 produces a 32-character URL-safe password in two seconds. pwgen -s 20 1 produces a secure 20-character password. Neither offers Diceware or pattern mode, but both are perfect for scripting.

Related Tools

Password generation is one step in a larger credential-management workflow. After generating, you typically hash the password (for verification), derive a key from it (for encryption), or compare it against a database (for migration). The tools below cover the adjacent steps.

The Hash Generator applies SHA-256, SHA-512, MD5, and other hash functions to arbitrary input - useful for verifying that two systems compute the same fingerprint for a password before migration. The Password Entropy Calculator computes the Shannon entropy of any password string you paste in, without generating - useful when auditing a legacy credential database.

The UUID Generator produces RFC 4122 v4 UUIDs (122 random bits in a canonical 36-character hex format) - the right primitive for opaque session tokens and API keys where you want a structured format rather than a freeform password. The QR Code Generator encodes a generated password into a scannable code, useful for Wi-Fi credentials and mobile-device pairing. The Barcode Generator handles the Code-128 and similar barcode formats sometimes used for hardware-token serial numbers.