Password Strength & Entropy Estimator (Patterns + Time)

No. Entropy measures resistance to brute-force attack against a uniform-random password drawn from a stated character set. It assumes the attacker doesn't know anything about the password's structure. Real attackers know plenty. Dictionary attacks try common words and phrases, rule-based mutations apply known substitutions (a to @, o to 0, s to $), and breach-corpus matching checks the password against billions of leaked passwords first. A 70-bit-entropy password that's actually `Summer2024!` falls in the first thousand attempts. Pair entropy math with a Have I Been Pwned check before trusting it.

Because it's a known pattern. The estimator detects keyboard walks, leetspeak substitutions, common words from the breach corpus, and predictable structure (capital first letter, digit and symbol at the end). Each of these reduces the effective search space. P@ssw0rd! looks like 8 characters drawn from a 95-character set (theoretical 52 bits) but is actually one of about 50,000 variants of "password" that an attacker tries first. The pattern penalty drops the score to reflect the real guessability, not the theoretical one.

No. All entropy and pattern computation happens locally in your browser via JavaScript. The password text never leaves your device. Even so, the security-hygiene rule still applies: don't type passwords you currently use on real accounts into unfamiliar tools, including this one. Use it for learning and for testing hypothetical passwords before adopting them.

Online attacks target a live login endpoint and are gated by the service's defenses (rate limiting, CAPTCHAs, account lockouts after N failures). Realistic ceilings are 10 to 100 guesses per second per account, often less. Offline attacks happen after a breach. The attacker has stolen password hashes and runs guesses against them on their own hardware, with no rate limits. Modern GPUs do billions of guesses per second against fast hashes (MD5, SHA-1, SHA-256), millions per second against slow hashes (bcrypt with cost 12, argon2id with reasonable parameters). The hash algorithm matters as much as the password.

Length. A 20-character lowercase passphrase like `correct horse battery staple` has higher entropy than an 8-character password mixing all four character classes (`Tr0ub4&!`). Length scales linearly in entropy bits per character. Adding complexity to a short password barely moves the math. NIST SP 800-63B's 2017 revision codified this. The document explicitly moved away from composition rules ("must include uppercase, digit, symbol") toward length minimums. For passwords you have to remember, use long passphrases. For passwords stored in a manager, use 20+ random characters from the full charset.

Order-of-magnitude accurate, not minute-accurate. The estimates assume a stated attack speed (online: 100/sec, offline-fast: 10 billion/sec, offline-slow: 100,000/sec) and uniform-random password generation. Real-world variance is large. Attackers have orders of magnitude more compute than they did five years ago, dictionary attacks short-circuit the brute-force timeline entirely, and the password's actual structure changes everything. Treat the numbers as relative ("this password resists offline GPU attack for years") rather than absolute ("this password takes exactly 14.7 years to crack").

Charset entropy assumes uniform randomness, with every position in the password independently drawn from the full character set. Shannon entropy measures the actual information content based on character frequency. `aaaaaaaaaa` has 10 characters from a 26-letter charset, charset entropy ~47 bits, but Shannon entropy near zero. There's almost no information after the first character. The estimator displays both because they catch different problems: charset entropy flags short passwords, Shannon entropy flags long-but-repetitive ones.

Usually yes, conditional on three things. The site uses a slow hash (bcrypt, argon2id, scrypt). Modern services almost always do, but legacy ones might not. The site has rate limiting and account lockout, which limits online attacks to ~100 guesses per second worst case. You enable MFA, which makes the password the second factor rather than the only one. With those in place, 12 random characters from the full charset (~78 bits of entropy) is solidly resistant. Without them, push to 16+. For password-manager-stored passwords, 20+ is the cheap default.

Because length asymmetrically affects offline attack feasibility. An 8-character password from the full charset has about 52 bits of entropy: guessable in days against fast hashes, hours against unsalted MD5. A 12-character password has about 78 bits: guessable in years against fast hashes. The transition between "trivial to crack" and "infeasible to crack" lives in the 10 to 14 character range. Anything shorter than 10 characters is short by modern standards regardless of how clever the symbols look.

No. Use the tool for learning, for testing patterns you're considering, and for evaluating auto-generated passwords before adopting them. Real passwords for live accounts shouldn't be typed into any unfamiliar tool, including this one. Not because we're sending them anywhere (we're not), but because security hygiene means never building habits where you type credentials into web pages. If you want to check whether one of your real passwords has been breached, use Have I Been Pwned's k-anonymity API. It never receives the full password.

Use a password manager (Bitwarden, 1Password, KeePassXC). Generated, unique, long passwords beat anything you can remember. Enable MFA everywhere it's offered, with hardware tokens or authenticator apps over SMS. Check your high-value accounts against Have I Been Pwned periodically. Don't reuse passwords across sites. And don't bother changing passwords on a fixed schedule unless there's a specific breach reason. NIST 800-63B's 2017 revision explicitly removed periodic-rotation guidance because it produces weaker passwords (users append `!` and increment numbers).

NIST 800-63B (revised June 2017) explicitly moved away from composition rules and toward length and breach-corpus checking. This tool's entropy estimate is the Shannon-style measure of guessability against a brute-force attacker. It doesn't model dictionary attacks or credential stuffing. NIST recommends checking new passwords against compromised password lists (e.g., HIBP's Pwned Passwords API) before accepting them. A 75-bit entropy score on this tool means a password is hard to brute-force. It doesn't mean it's hard to guess. Pair entropy with a breach check for production use. The math is necessary, not sufficient.