Password Generator
Password Generator creates cryptographically secure passwords, memorable passphrases and numeric PINs using your browser's crypto.getRandomValues() — the operating system's kernel entropy pool, never Math.random(). A live meter shows entropy bits, a strength rating and a realistic brute-force time estimate. Everything happens on your device; no password is ever transmitted.
Estimated time to brute-force: longer than the age of the universe (10 billion guesses/second)
How secure password generation actually works
Every password on this page is drawn from the Web Cryptography API, the browser's interface to the operating system's cryptographic randomness source. On Linux and macOS that source is the kernel's /dev/urandom pool, continuously reseeded from hardware entropy — interrupt timing jitter, thermal sensor noise, and disk I/O latencies that no remote observer can predict or replay. On Windows it is BCryptGenRandom, the system CNG provider. The alternative most quick scripts reach for, Math.random(), is a deterministicxorshift128+ generator seeded once per page load: its entire future output is computable from a few observed values, and seeded PRNGs have been broken in public demonstrations in milliseconds. The distinction is not academic — it is the difference between a secret and a puzzle.
Uniform sampling without modulo bias
Converting random bytes into random characters has a classic trap. If you take a random byte (0–255) and compute byte % 62 to index a 62-character alphabet, the values 0–7 occur slightly more often than 8–61, because 256 is not a multiple of 62. Over millions of passwords that bias is measurable, and measurable bias is information an attacker can use. This generator usesrejection sampling: it draws 32-bit values and discards any that fall in the ragged top region that would make the modulus uneven, redrawing until the value is in the clean range. For the alphabet sizes used here the discard rate is under 2%, the cost is invisible, and every character position is exactly uniform.
What “128 bits of entropy” means in practice
Entropy in bits is length × log₂(alphabet size). A 20-character password from an alphabet of 90 symbols carries about 130 bits: an attacker guessing at 10 billion candidates per second — roughly eight top-end GPUs running optimized hashcat — would need on average 2^129 ÷ 10^10 seconds, or about 10^28 years. The age of the universe is 1.4 × 10^10 years. This is why the meter's top band reads “longer than the age of the universe”: it is not marketing copy, it is arithmetic. The practical takeaway is that anything above ~80 bits is already beyond any plausible brute-force attack, and the remaining risk in real breaches is almost never brute force — it is phishing, credential stuffing from other breaches, and unpatched software.
Passphrases: entropy you can remember
The passphrase mode is inspired by Randall Munroe's xkcd #936, where four words from a 2,048-word list carry 11 bits per word (44 bits total). Because this generator embeds a compact 1296-word list of short, unambiguous words (log₂(1296) ≈ 10.34 bits per word), a 4-word passphrase carries 41.36 bits of entropy on its own, or 44.68 bits with the default appended digit (+ log₂(10) ≈ 3.32 bits), and an 8-word passphrase with a digit reaches 86.04 bits. The live meter reports this exact figure rather than inflating it. Use 4-word passphrases only for low-stakes, rate-limited logins you type by hand; for a password-manager master password, full-disk encryption, or any secret that must resist offline cracking, switch to Password mode (16–20+ random characters for 105–130+ bits) or use a full 2,048–7,776-word Diceware list.
PINs and the leading-zero trap
A six-digit PIN has only about 20 bits of entropy (6 × log₂10 ≈ 19.9) — the meter will honestly label it “weak”. PINs are appropriate only where the system rate-limits attempts (phone unlock, SIM PIN, a door code), never as a standalone online secret. One implementation detail matters: PINs are generated digit-by-digit as strings, so a PIN like 042817 keeps its leading zero. Generators that produce a random integer and convert it to text silently drop leading zeros, shrinking the space from 10^6 to ~9×10^5 possibilities and — worse — producing a 5-digit output the user didn't ask for.
The threat model this tool addresses — and the one it doesn't
This tool eliminates exactly one risk: the password itself being weak, predictable, or exposed in transit during generation. It does not protect you from phishing pages that ask you to type the strong password you just made, from malware reading your clipboard, or from reusing the password across sites (use a password manager; that is what the bulk mode and copy buttons are for). The history panel is session-only JavaScript memory — it is a convenience for recovering a password you generated but forgot to copy, not a vault. Generate here, store in a manager, clear the history, close the tab. That is the complete workflow this page is designed around.
Which keyboard shortcuts does the password generator support?
Frequently asked questions
Why is a client-side password generator more trustworthy than a server-side one?
A password is the one secret that must never travel. When a website generates your password on its server, the plaintext value exists — however briefly — in that server's memory, logs, and potentially backups, and you have no way to verify it was deleted. A client-side generator calls crypto.getRandomValues() in your own browser, which draws from your operating system's kernel entropy pool (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). The generated password never leaves your device: there is no HTTP request, no analytics event, no server log. You can verify this yourself by opening the browser's network tab while generating — it stays silent. That verifiability is the entire trust argument.
What does the entropy meter actually measure?
Entropy, in bits, is length × log₂(alphabet size). A 20-character password drawn from 90 possible symbols carries about 130 bits of entropy, meaning an attacker must try on average 2^129 candidates. The strength bands follow the standard interpretation: under 50 bits is weak (crackable by a hobbyist rig), 50–80 is fair, 80–128 is strong, and above 128 bits is effectively unbreakable — 2^128 operations exceeds the energy budget of any physically realizable computer. The 'time to crack' readout assumes 10 billion guesses per second, roughly a serious multi-GPU rig running optimized hashing, and shows the average (half the keyspace) rather than the worst case.
Passphrase or random password — which should I use?
It depends on the threat model and word list size. This tool's built-in passphrase list has 1296 common words (log₂1296 ≈ 10.34 bits per word), so a 4-word passphrase provides 41.36 bits of entropy (or 44.68 bits with the default trailing digit) and an 8-word passphrase provides about 82.72 bits (86.04 bits with the trailing digit). That makes the 4-word passphrase convenient for low-risk or rate-limited logins you type by hand, but too weak for a password manager master password or disk encryption. For a master password, disk encryption, or any high-value secret that faces offline cracking, use a 16–20+ character random password from Password mode (105–130+ bits) or a full 2,048–7,776-word Diceware list. Never use song lyrics, quotes, or Bible verses as passphrases: attackers maintain dictionaries of exactly those.
Why does the generator guarantee one character from each set?
Many sites enforce composition policies ('must contain an uppercase letter and a digit'). A purely uniform draw can — rarely — produce a password missing a required class, forcing the user to regenerate and weakening the effective process. This generator draws one character from each enabled set first, fills the remainder uniformly from the full alphabet, then shuffles with a Fisher–Yates pass driven by the same cryptographic RNG. The result satisfies composition policies by construction while the shuffle keeps the guaranteed characters from clustering at the front, which would leak structure to an attacker.
Is Math.random() really that bad for passwords?
Yes, categorically. Math.random() is typically a xorshift128+ PRNG seeded once per page load from a 64-bit seed. Anyone who observes a few outputs — or who can guess the seed from timing — can predict every subsequent value. There are published demonstrations of recovering the seed from a handful of outputs in milliseconds. crypto.getRandomValues(), by contrast, is a cryptographically secure PRNG backed by the OS kernel's entropy pool, which mixes hardware events (interrupt timing, thermal noise) that no remote attacker can observe or reproduce. This page never calls Math.random() for anything secret.
Should I use the history feature for passwords I actually use?
The history is a convenience for the generation session: it keeps your last 10 outputs in the tab's JavaScript memory so you can recover one you generated but didn't copy. It is never written to disk, localStorage, or cookies, and it vanishes when the tab closes. That said, treat it as ephemeral scratch space, not storage — once you've pasted a password into your password manager, clear the history. Your password manager (with its encrypted vault) is the correct long-term home for secrets, not a browser tab.