Password Generator
Generate cryptographically random passwords in your browser using
crypto.getRandomValues() — no passwords are transmitted or stored.
Last reviewed 2026-06-19.
How password strength is measured
Strength is calculated from entropy — the number of bits of unpredictability in the password. Each character drawn from a pool of N possible characters contributes log₂(N) bits; a password of length L gives L × log₂(N) bits total.
| Entropy | Rating | Approximate crack time (fast GPU) |
|---|---|---|
| < 40 bits | Weak | Seconds to hours |
| 40–59 bits | Fair | Hours to weeks |
| 60–79 bits | Strong | Centuries |
| ≥ 80 bits | Very Strong | Longer than the age of the universe |
Example: a 16-character password from a mixed pool of 86 characters (uppercase + lowercase + digits + symbols) has 16 × log₂(86) ≈ 102.8 bits — comfortably in the "Very Strong" range and infeasible to brute-force with any current hardware.
Password security tips
- Length beats complexity. A 20-character lowercase-only password is far stronger than an 8-character mixed-case password. Entropy scales linearly with length but only logarithmically with pool size.
- Use a unique password for every account. Credential reuse is the most common cause of real-world account takeovers. Password managers make this easy.
- Never use dictionary words or personal information — birthdays, names, and common word substitutions (p@ssw0rd) are the first things brute-force dictionaries try.
- Enable two-factor authentication (2FA) wherever possible. Even a compromised password cannot be used without the second factor.
- Store passwords in a manager (Bitwarden, 1Password, KeePass, Apple Passwords). Never write them down or reuse them.
Character sets used
| Set | Characters | Pool size |
|---|---|---|
| Uppercase | A–Z | 26 (24 excl. ambiguous) |
| Lowercase | a–z | 26 (23 excl. ambiguous) |
| Numbers | 0–9 | 10 (8 excl. ambiguous) |
| Symbols | !@#$%^&*()-_=+[]{}|;:,.? | 24 |
What modern password guidance actually says (NIST SP 800-63B)
The authoritative reference for password rules is the U.S. National Institute of Standards and Technology Special Publication 800-63B (the latest revision, SP 800-63B-4, was finalised in 2024). Its advice overturned decades of frustrating habits, and it is worth knowing because it explains why this generator is built the way it is:
- Length is the priority. A minimum of 8 characters is required, but systems should allow at least 64, and NIST encourages long passwords and passphrases.
- No mandatory composition rules. NIST explicitly advises against forcing a mix of
uppercase, lowercase, digits and symbols. Such rules push people toward predictable patterns
(
Password1!) and add little real entropy compared with simply adding length. - No forced periodic changes. Routine 90-day expiry is discouraged; passwords should be
changed only when there is evidence of compromise. Forced rotation just produces weak, incremental
variations (
Spring2025thenSummer2025). - Screen against breached passwords. Systems should reject passwords found in known breach lists — the real-world risk is not that an attacker guesses your password from scratch but that they try one already leaked from another site.
- Allow everything, and allow pasting. All printable ASCII, spaces and Unicode should be accepted, and paste should be permitted so password managers work.
The throughline is simple: a long, unique, random secret beats a short, "complex" one — which is exactly what this tool produces.
Passphrases: strong and memorable
Random character strings are ideal when a password manager will remember them for you. But for the handful of passwords you must memorise — your device login, your password-manager master password — a random passphrase is often better, because it is far easier to remember at the same strength. The standard method is Diceware: pick words at random from a list of 7,776 (that is 65, the outcomes of five dice). The Electronic Frontier Foundation's word list adds about 12.9 bits of entropy per word, so a six-word passphrase carries roughly 77 bits — comfortably strong — while remaining something you can actually recall. The famous xkcd example "correct horse battery staple" (four words) illustrates the idea, though at four words it is only around 44–52 bits; six words is the modern recommendation. The crucial requirement is that the words be chosen randomly — a phrase you invent yourself, or a quotation, has far less entropy than the word count suggests, because it is predictable.
Online vs offline attacks: why crack times vary so much
The crack-time figures in the table above assume an offline attack — the scenario that sets how strong a password really needs to be. It helps to distinguish two very different situations:
- Online attacks try passwords against a live login. They are slow and easily defeated: rate limiting, lockouts and CAPTCHAs cap an attacker at a handful of guesses, so even a fairly weak password resists online guessing.
- Offline attacks happen after a database is stolen. The attacker holds the password hashes and can guess as fast as their hardware allows — billions of attempts per second on a modern GPU. This is where high entropy matters, because there is no rate limit to slow them down.
Offline speed also depends entirely on how the site stored your password. A site that used a deliberately slow, salted algorithm (bcrypt, scrypt, Argon2) might allow only thousands of guesses per second; a site that foolishly used a fast, unsalted hash such as raw MD5 or SHA-1 allows billions. You cannot control which a given site chose — which is the real reason to make every password long and unique: length protects you even against the careless sites.
How passwords should be stored: hashing and salting
A well-built service never stores your actual password. Instead it stores a hash — a one-way fingerprint that cannot be reversed to recover the original — produced by a purpose-built password-hashing function such as Argon2, scrypt, bcrypt or PBKDF2. Two extra ingredients harden this further. A salt is a unique random value mixed into each password before hashing, so identical passwords produce different hashes and a precomputed "rainbow table" of common hashes is useless. A pepper is an additional secret kept separate from the database. These functions are deliberately slow, which barely affects a single legitimate login but cripples an attacker trying billions of guesses. When you read that a breach exposed "hashed and salted" passwords, that is this protection working — and it is another reason a long, random password buys you time even after a breach.
The attacks a strong password defends against (and the ones it doesn't)
Different threats call for different defences, and it is worth being honest about where password strength helps and where it does not:
- Brute force — trying every combination. High entropy defeats it outright; this is what the bit counts measure.
- Dictionary attacks — trying words, names and common substitutions
(
p@ssw0rd). A truly random password is immune; a clever-looking human one often is not. - Credential stuffing — replaying username and password pairs leaked from one site against many others. This is defeated only by using a different password on every site, which is why reuse is the single most dangerous habit and a password manager the single best fix.
- Phishing, keyloggers and malware — these capture the password as you type it, so no amount of strength helps. The defences here are two-factor authentication, vigilance about fake login pages, and keeping your devices clean.
In other words, a strong, unique password is necessary but not sufficient. Pair it with 2FA and a password manager and you close the gaps that strength alone cannot.
Why true randomness matters: CSPRNG vs Math.random
A password is only as unpredictable as the randomness behind it. JavaScript's Math.random() is a
fast pseudo-random generator never intended for security — its output can be predicted or reproduced, so it
must never be used to make secrets. This tool instead uses
crypto.getRandomValues(), the browser's cryptographically secure generator,
which draws on the same operating-system entropy that protects TLS and password managers. It also applies
rejection sampling to avoid "modulo bias": naïvely mapping a random byte onto a character
pool would make some characters slightly more likely than others, so any value that would skew the result is
discarded and re-drawn. The effect is that every character is chosen with genuinely equal probability — the
assumption the entropy maths above depends on.
The future: passkeys and WebAuthn
The long-term answer to password problems is to stop using passwords at all. Passkeys, built on the WebAuthn / FIDO2 standards, replace shared secrets with public-key cryptography: your device holds a private key, the site holds only the matching public key, and you authenticate with a fingerprint, face or PIN. Because nothing reusable is ever sent, passkeys are inherently resistant to phishing and credential stuffing — there is no password to steal, leak or be tricked into typing. Adoption is growing across major platforms, but passwords will remain everywhere for years yet, so generating a strong, unique one for each account — and storing it in a manager — remains essential today.
Two-factor authentication: the second layer
Because even a perfect password can be phished or captured, the most important thing you can add to an account is a second factor — something beyond the password. The strongest common option is a hardware security key (a FIDO2/WebAuthn device) or a passkey, both of which are phishing-resistant because they will only authenticate to the genuine site. Next best is an authenticator app generating time-based one-time codes (TOTP), which never leave your device. Weakest, but still far better than nothing, is SMS — convenient, but vulnerable to SIM-swapping and interception, so avoid it for high-value accounts where an app or key is available. Turn on a second factor everywhere it is offered, starting with your email and your password manager, since those unlock everything else.
How password managers work
A password manager solves the core dilemma — that strong passwords are, by design, impossible to remember — by storing all of them in an encrypted vault locked behind a single master password (the one passphrase you do memorise). The vault is encrypted on your own device before it is ever synced, so a well-built manager never has access to your passwords; only your master password can decrypt them. That lets you give every site a unique, long, random secret like the ones this tool generates, eliminating reuse — the single biggest real-world cause of account takeover — without any memory burden. Reputable options include Bitwarden, 1Password, KeePass and the managers built into modern browsers and operating systems. The one password worth memorising really well is the master password protecting the vault.
How length and pool size combine
Because entropy is length × log₂(pool), both levers matter, but length is the more powerful one. The table below shows the approximate entropy of an all-random password drawn from the full 94-character printable-ASCII set at several lengths, and why short passwords fail no matter how "complex" they look:
| Length | Entropy (94-char pool) | Rating |
|---|---|---|
| 8 characters | ≈ 52 bits | Fair — crackable offline |
| 12 characters | ≈ 79 bits | Strong |
| 16 characters | ≈ 105 bits | Very strong |
| 20 characters | ≈ 131 bits | A sensible default for high-value accounts |
The jump from 8 to 16 characters more than doubles the entropy and moves a password from "breakable with effort" to "infeasible with any foreseeable hardware" — which is why the single best thing you can do is make your passwords longer.
Frequently asked questions
- Is this password generator truly random?
- Yes. This generator uses your browser's built-in crypto.getRandomValues() API, which draws entropy from the operating system's CSPRNG (cryptographically secure pseudo-random number generator). Unlike Math.random(), which is not designed for security, crypto.getRandomValues() is the standard used by password managers, TLS, and other cryptographic software.
- Does my password leave the browser?
- No. Password generation happens entirely in your browser using local CPU and OS entropy. Nothing is uploaded, transmitted or logged. The page also works offline once loaded.
- How long should a password be?
- Length is the single most important factor. A random 16-character password drawn from a mixed pool produces around 100 bits of entropy — effectively uncrackable by any current hardware. Most security experts recommend at least 16 characters for general use and 20+ for high-value accounts. Short passwords (8 characters or fewer) can be brute-forced in hours even with complex character sets.
- What does "exclude ambiguous characters" do?
- It removes characters that look similar in some fonts: uppercase I (looks like lowercase l or digit 1), uppercase O (looks like digit 0), lowercase l and digit 1, lowercase o and digit 0. Excluding them makes the password easier to read and transcribe if you ever need to type it manually. The entropy reduction is small — typically 3–5 bits — and usually worth the reduced transcription errors.
- What is password entropy and how is it calculated?
- Entropy, measured in bits, is a mathematical measure of unpredictability. A password drawn randomly from a pool of N distinct characters has log₂(N) bits of entropy per character; a password of length L therefore has L × log₂(N) bits total. As a practical guide: below 40 bits is weak (minutes to crack), 40–59 bits is fair (hours to days), 60–79 bits is strong (years with current hardware), and 80+ bits is very strong (infeasible with any foreseeable hardware).
- Should I use a password manager?
- Yes, strongly. A password manager (Bitwarden, 1Password, KeePass, Apple Passwords, or similar) stores your passwords encrypted behind a single master password. This lets you use a unique, long, random password for every site — eliminating credential reuse, which is the most common cause of account takeovers. Generate a fresh password here for each account and let the manager remember it.