Password Generator

What makes a password strong?

A strong password is one that is computationally infeasible to guess, whether an attacker is trying common passwords online or running billions of guesses per second against a stolen database offline. The single most important factor is not which symbols you sprinkle in, but how much genuine unpredictability — entropy — the password contains. Entropy is measured in bits, and each additional bit doubles the number of guesses an attacker must make. A password with 80 bits of entropy is over a trillion times harder to crack than one with 40 bits.

Two things drive entropy: the size of the character pool you draw from and the length of the password. Lowercase letters alone give a pool of 26; adding uppercase, digits and symbols grows it to roughly 94. But length matters even more, because entropy grows linearly with length and only logarithmically with pool size. Adding one more random character multiplies the keyspace by the whole pool size, which is why a long passphrase of ordinary words can be far stronger than a short string of gibberish. The practical rule is simple: prefer length, and let a generator supply the randomness.

Crucially, entropy only counts if the characters are actually random. A password that looks complex but follows a human pattern — a capital at the start, a digit and a symbol at the end, a dictionary word in the middle — has far less effective entropy than its length suggests, because attackers model exactly those patterns. This is why a password you invent in your head is almost always weaker than one a cryptographically secure generator produces, even when they are the same length. The generator on this page draws every character from crypto.getRandomValues(), so the strength you see is the strength you get.

Finally, a strong password is a unique password. Even a perfect 20-character password offers no protection if you reuse it on a site that gets breached and leaks it, because attackers immediately try that exact password on your email, bank and everything else — an attack called credential stuffing. Strength and uniqueness work together: generate a different strong password for every account and store them in a password manager.

How long should a password be?

For a typical online account protected by a password manager, aim for at least 16 characters of random text, which yields roughly 100 bits of entropy with a full character set — comfortably beyond what any attacker can brute-force today or in the foreseeable future. Many security teams now set 16 as the floor precisely because it removes the password from realistic offline cracking range even against fast hardware. If you are choosing a passphrase you have to remember, target five to seven random words, which lands in the same 64–90+ bit range while staying typeable.

Length requirements scale with the value of what you are protecting and how the password is stored. A throwaway forum login behind rate limiting can survive on less, but a master password, a disk-encryption passphrase, a root or domain-admin account, or any secret that protects other secrets should be longer — 20 to 30 characters or six to eight words. Service accounts and API secrets, which are never typed by a human, can and should be longer still, often 32 characters or more, because there is no usability cost to making them maximal.

There is an upper bound where extra length stops adding meaningful security and starts causing compatibility headaches: some systems silently truncate long passwords, and bcrypt ignores anything past 72 bytes. Beyond about 40 random characters (roughly 256 bits) you have already exceeded the security of the encryption protecting the rest of the system, so going further is symbolic rather than useful. This tool lets you go up to 256 characters for those edge cases, but for almost everyone, 16–24 random characters or a six-word passphrase is the sweet spot of strength and practicality.

What is password entropy and how is it calculated?

Password entropy is a measure, in bits, of how unpredictable a password is — equivalently, the base-2 logarithm of the number of equally likely passwords an attacker would have to consider. For a password generated by choosing each character independently and uniformly from a pool of size N, the entropy is length × log₂(N). A 12-character password from the 94-character printable-ASCII set therefore carries 12 × log₂(94) ≈ 78.7 bits. Each added character adds another log₂(94) ≈ 6.6 bits, and each bit doubles the attacker’s work.

For passphrases the maths is even cleaner: if you pick each word uniformly from a list of L words, every word contributes log₂(L) bits. Choosing six words from a 2,000-word list gives 6 × log₂(2000) ≈ 66 bits — and unlike character-based estimates, this figure is exact because the words really are chosen at random. That is why this generator reports passphrase entropy from the actual length of the wordlist it used, rather than guessing. It is also why adding a digit or symbol to a passphrase adds only a few bits: the words are already doing the heavy lifting.

The entropy formula assumes every character or word is independent and random, which holds for generated secrets but not for human-chosen ones. A password like “Summer2024!” has a theoretical 11 × log₂(94) ≈ 72 bits, but its effective entropy is a tiny fraction of that, because an attacker’s wordlist-and-rules engine will try “Season+Year+Symbol” combinations long before random ones. The analyzer on this page estimates effective entropy by detecting these patterns and discounting accordingly, giving you a realistic picture rather than a flattering theoretical one.

How are passwords cracked?

Password attacks fall into two broad camps. Online attacks target a live login form or API, submitting guesses one request at a time; they are slow and noisy, and any competent service throttles or locks accounts after a handful of failures, so even a modest password resists them. Offline attacks are the real threat: when a service is breached and its password database is stolen, attackers crack the hashes on their own hardware with no rate limit, testing millions to billions of candidates per second depending on how the passwords were hashed.

Attackers rarely brute-force blindly. They start with the highest-probability guesses: lists of the most common passwords, every entry from previous breaches (there are billions), dictionary words, and then those words transformed by rules — capitalising, appending years and symbols, swapping letters for look-alike digits (leetspeak). Tools like Hashcat and John the Ripper apply thousands of such rules per second, which is why “P@ssw0rd123” falls almost as fast as “password”. Only after these targeted strategies are exhausted does pure brute force begin, and by then a truly random password is the only kind left standing.

The speed of offline cracking depends entirely on how the stolen passwords were hashed. Passwords stored with a fast general-purpose hash like MD5 or SHA-256 can be tested at tens of billions per second on a single GPU; the same passwords protected by a slow, salted, memory-hard function like Argon2 or bcrypt drop to thousands or fewer per second, multiplying the attacker’s cost by millions. As a user you cannot control how a site hashes your password, so your defence is entropy and uniqueness: a high-entropy password survives even a fast-hash breach, and a unique one limits the damage to a single site.

Dictionary, brute force, credential stuffing & password spraying

A dictionary attack tries a curated list of likely passwords — real words, names, common passwords and their predictable mutations — rather than every possible string. It works because most human passwords are built from words, so the attacker reaches them in millions of guesses instead of quintillions. A pure brute-force attack, by contrast, tries every combination of characters up to some length; it is guaranteed to succeed eventually but is only practical against short or low-entropy passwords. Real-world cracking blends the two: dictionaries and rules first, brute force for what remains.

Credential stuffing is the attack that makes password reuse so dangerous. After a breach leaks millions of email-and-password pairs, attackers replay those exact pairs against other sites — banks, email providers, retailers — betting that many people reused the same password. Because the credentials are already valid somewhere, success rates are high and the attack needs no guessing at all. The only defence is to never reuse a password, which is precisely what a generator plus a password manager makes effortless.

Password spraying flips brute force on its head to evade lockouts: instead of many guesses against one account, the attacker tries one or a few very common passwords (“Spring2024!”, “Welcome1”) against many accounts. Because each account sees only one or two attempts, lockout thresholds are never tripped, yet across thousands of accounts some will be using that common password. Spraying targets the weakest passwords in a population, so generating a strong, non-obvious password keeps you out of the attacker’s small high-probability list entirely.

Rainbow tables, salting and why fast hashes fail for passwords

A rainbow table is a precomputed mapping from hashes back to the passwords that produced them, cleverly compressed so a huge number of candidates fit in manageable storage. If a site stores passwords as a bare, unsalted hash, an attacker who steals the database can simply look each hash up in a rainbow table and recover the password instantly, without doing any cracking at all. This is why unsalted hashing is considered broken for password storage regardless of which hash algorithm is used.

The defence is a salt: a unique random value added to each password before hashing. Salting guarantees that two users with the same password get different hashes, and it makes precomputed tables useless, because the attacker would need a separate table for every possible salt. Modern password-hashing functions add salt automatically and store it alongside the hash. They also add a deliberately high computational cost — a work factor — so that even with the salt known, each individual guess is slow and expensive to test.

This is the heart of why a fast hash like SHA-256, excellent for file integrity, is the wrong tool for passwords: it is too fast, letting attackers test billions of salted guesses per second. Purpose-built functions — Argon2id, scrypt, bcrypt and PBKDF2 — are slow and, in the case of Argon2 and scrypt, memory-hard, which defeats the parallelism of GPUs and custom cracking hardware. None of this is something you configure as an end user; it is the server’s job. Your job is to supply a high-entropy password so that even if a site does everything wrong, your account stays safe.

Password security best practices

The modern consensus, codified in NIST 800-63B, is shorter than the old folklore: use long, unique passwords; do not reuse them; do not rotate them on a fixed schedule unless there is evidence of compromise; and screen them against lists of known-breached passwords. The discredited advice to force complex composition rules and 90-day expiry actually weakened security, because it pushed people toward predictable patterns like “Password1!” → “Password2!”. Length and uniqueness, backed by breach screening, deliver far more protection with far less friction.

Use a password manager. It is the single highest-impact change most people can make, because it removes the reason people reuse passwords in the first place: the impossibility of remembering hundreds of unique ones. A manager generates, stores and autofills a different strong password for every account, and its autofill is itself a phishing defence, since it refuses to fill credentials on a look-alike domain. You then only need to remember one strong master passphrase and protect it well.

Layer on multi-factor authentication wherever it is offered, preferring phishing-resistant factors — passkeys, security keys (FIDO2/WebAuthn) or authenticator apps — over SMS, which can be intercepted via SIM-swapping. MFA means that even a stolen or guessed password is not enough to take over an account. Treat your email and password-manager master credentials as the crown jewels, since they can reset everything else, and give them your longest, most unique secrets plus a hardware-backed second factor.

For developers and administrators, the same principles extend to machine credentials: generate API keys, tokens and service-account passwords with a CSPRNG, give each service its own secret, store secrets in a vault or secrets manager rather than in code or environment files committed to git, and rotate them on compromise. Never log secrets, never email them in plain text, and prefer short-lived, automatically rotated credentials where your platform supports them.

Why passphrases work (the Diceware approach)

A passphrase is a password made of several random words, like “anchor-velvet-cobra-meadow-ledger”. The Diceware method popularised generating them by rolling physical dice to index into a numbered wordlist, guaranteeing that each word is chosen uniformly at random. The appeal is human: a string of real words is dramatically easier to remember and to type accurately than an equivalent length of random symbols, yet it can carry just as much entropy if the words are genuinely random and drawn from a large enough list.

The strength of a passphrase comes entirely from the number of words and the size of the list — not from the words being obscure. Six words chosen from a 2,000-word list give about 66 bits of entropy whether the words are common or rare, because the attacker’s effort depends on how many equally likely combinations exist, not on how unusual any single word looks. This is why this generator quotes passphrase entropy directly from the wordlist length, and why it offers lists in several languages: the security is identical as long as the selection is random.

Passphrases shine for the secrets you must type from memory — your password-manager master password, your laptop’s disk-encryption passphrase, an SSH key passphrase — where a manager can’t autofill for you. For everything else, a shorter fully-random password stored in a manager is more efficient. A common mistake is to invent a “passphrase” from a famous quote or song lyric; those are in attackers’ wordlists and offer almost no entropy. Always let the tool pick the words at random.

Passwords, MFA, passkeys and zero trust

A password is a single authentication factor — “something you know”. Multi-factor authentication adds at least one more factor, “something you have” (a phone, security key or passkey) or “something you are” (a fingerprint or face), so that compromising the password alone is not enough. Because phishing and breaches will always recover some passwords, MFA is the safety net that keeps a leaked password from becoming a lost account. Authenticator-app codes and hardware security keys are far stronger second factors than SMS one-time codes.

Passkeys are the emerging successor to passwords, built on the FIDO2/WebAuthn standards. Instead of a shared secret you both know, your device holds a private key and the site holds the matching public key; you authenticate by proving possession of the private key, usually unlocked with your device biometric. Passkeys cannot be phished, reused or leaked in a breach, because there is no secret on the server to steal. Where a service offers passkeys, they are the strongest option — but passwords remain essential everywhere passkeys are not yet supported, and a strong generated password is still your baseline.

Zero trust is the organisational philosophy that no user or device is trusted by default, even inside the network: every access request is authenticated, authorised and continuously verified. Strong, unique credentials and phishing-resistant MFA are the foundation of a zero-trust posture, because identity becomes the new perimeter. Generating high-entropy passwords and secrets, storing them in a vault, and pairing them with MFA or passkeys is exactly the credential hygiene a zero-trust model depends on.

NIST and OWASP password guidelines

NIST Special Publication 800-63B is the most influential modern password standard. Its headline guidance: allow passwords of at least 8 characters and up to at least 64, accept all printable ASCII and Unicode (including spaces and emoji), screen new passwords against lists of compromised values, and do not impose composition rules or periodic expiration. The philosophy is that usability and length-first thinking produce stronger real-world security than complexity theatre, and that breached-password screening catches the weak choices that rules used to chase.

OWASP’s Application Security Verification Standard (ASVS) aligns closely and adds developer-focused requirements: a 12-character minimum for new passwords, no truncation, no silent character stripping, secure storage with a salted slow hash such as Argon2id or bcrypt, rate limiting and lockout to blunt online guessing, and support for password managers (don’t block paste). OWASP also recommends checking passwords against the Have I Been Pwned breach corpus so users can’t pick a password already known to attackers.

This tool’s policy validator encodes both standards so you can check a candidate password against NIST and OWASP directly, alongside compliance regimes like PCI DSS and ISO 27001 and identity platforms like Active Directory and Entra ID. The generator’s NIST and OWASP presets produce passwords that satisfy these guidelines out of the box — long, high-entropy and free of the predictable patterns that breach lists target.

// Cryptographically secure password — browser or Node 18+
function generatePassword(length = 20) {
  const charset =
    'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+';
  const out = [];
  const max = Math.floor(0xffffffff / charset.length) * charset.length;
  const buf = new Uint32Array(1);
  while (out.length < length) {
    crypto.getRandomValues(buf);
    if (buf[0] < max) out.push(charset[buf[0] % charset.length]); // unbiased
  }
  return out.join('');
}
console.log(generatePassword(24));