You changed the “o” to a “0”, swapped an “a” for ”@”, and tacked “123!” onto the end. Your password P@$$w0rd123! looks like it would give any attacker a migraine. In reality, it falls in seconds. The problem isn’t that you chose bad characters. The problem is that entropy, the actual measure of password strength, has nothing to do with visual complexity and everything to do with how an attacker thinks. This article breaks down how the system calculates Shannon entropy, why pattern detection matters more than character variety, and how to read real crack-time estimates across different attack scenarios. By the end, you’ll understand exactly why your current password is weaker than it looks, and what to do about it.
Why Offline Password Analysis Matters
Most password strength meters work the same way: you type your password, it travels to a server, the server evaluates it, and a response comes back telling you “strong” or “weak.” That workflow has a flaw that rarely gets discussed. The password you just typed, the real one you use every day, left your device and crossed at least one network hop before the feedback appeared. The security check itself became a data exposure event.
CapyToolkit takes a different approach to browser-based security tools. The tool for analysing password entropy in your browser runs entirely client-side using TypeScript for the Shannon entropy calculation and a zxcvbn pattern model that loads locally as a JavaScript module. The application transmits nothing. The module files load on demand the first time you click the input field, your browser caches them, and every subsequent analysis runs in local memory. After that initial load, there are zero outbound requests.
You can verify this yourself. Open DevTools, switch to the Network tab, load the page, and then disconnect from the internet. Type any password. The tool keeps working because all the analysis logic is already cached in your browser. This matters because evaluating a real password on a server-side meter means trusting that server operator with your credential. For anyone who takes that tradeoff seriously, local analysis is the only option that closes the loop.
Shannon Entropy and the Math Behind Password Strength
Processing these structural checks locally requires a standardized metric to score a string’s defense capabilities. Shannon entropy measures unpredictability, not complexity. It counts the bits of uncertainty an attacker must resolve to guess your password through brute force, assuming they know your character set but not which specific characters you chose. Wikipedia’s overview of password strength covers the relationship between Shannon entropy and information theory in more detail. The formula is straightforward: H = L × log₂(poolSize), where L is the password length and poolSize is the number of distinct characters available.1
Pool size comes from which character classes appear in the password. Lowercase letters contribute 26 characters, uppercase adds another 26, digits add 10, and printable ASCII symbols add 33, giving a maximum pool of 95. Each class you include expands the keyspace because a brute-force scanner must test every position against the entire alphabet. Adding even one uppercase letter grants the full 26-character uppercase pool, since the attacker has no way to know which positions contain which class. To see how these character selections scale your total keyspace, consider how changing the pool shifts the bit-strength of standard 8-character and 12-character strings:
| Character Pool | Pool Size | Bits per Character | 8-char Entropy | 12-char Entropy |
|---|---|---|---|---|
| Lowercase only (a-z) | 26 | 4.70 | 37.6 bits | 56.4 bits |
| Lower + upper (a-z, A-Z) | 52 | 5.70 | 45.6 bits | 68.4 bits |
| Alphanumeric (a-z, A-Z, 0-9) | 62 | 5.95 | 47.6 bits | 71.4 bits |
| Full ASCII printable | 95 | 6.57 | 52.6 bits | 78.8 bits |
A 12-character password using the full 95-character set yields roughly 78.8 bits of entropy, meaning an attacker must resolve approximately 2⁷⁸·⁹ possible combinations to guarantee a hit. That figure looks solid until you realize the formula assumes you selected every character randomly from the full pool. Humans don’t select randomly.
A 15-character all-digit password like 483920174839201 carries only 49.8 bits of entropy because the formula strictly bounds the calculation to a pool size of 10. An attacker targeting digit-only combinations exhausts that space almost instantly. The tool accounts for this by displaying the lower of the Shannon entropy and the zxcvbn estimate, always showing the more pessimistic and realistic score.
zxcvbn Pattern Analysis: Why Smart Attackers Skip the Keyspace
Shannon entropy models a brute-force attacker who tests every possible combination across the full keyspace. Real attackers are smarter than that. zxcvbn models an attacker who starts with common passwords, applies dictionary lookups, and runs systematic mutations before ever touching random combinations. Dropbox’s original zxcvbn research paper explains the pattern-matching approach and why it produces more realistic strength estimates than formula-based methods.2 The gap between the two models explains why so many “complex” passwords fail in practice.
The tool detects five pattern categories, each representing a structure that cracking software tests early:
- Dictionary: matched a common English word, name, or well-known password pattern like
PasswordorWelcome1 - Keyboard walk: follows adjacent key rows or columns:
qwerty,asdfg,1qaz2wsx - Repeated characters: repeating substrings like
aaaa,abababab,xyzxyz - Sequential characters: consecutive alphabet or number sequences:
abcd,1234,zyxw - Date pattern: embedded dates in common formats like
19870612orJun1987
Take P@$$w0rd123 as a concrete example. It uses uppercase, symbols, and digits, giving a pool size of 95 and over 70 bits of Shannon entropy. Yet it scores Very Weak because the substitution pattern (@ for a, $ for s, 0 for o) appears in virtually every password cracking ruleset. zxcvbn recognizes those substitutions because they are common in password-cracker dictionaries, not because they make the string harder to guess. The l33t speak that feels clever to a human is the first thing automated tools try.
When the two signals disagree, always trust the lower one. If Shannon entropy says 70 bits but zxcvbn says “Very Weak,” the password is very weak. Smart attackers skip the full keyspace and go straight for recognizable patterns, so a low zxcvbn score is more dangerous than high entropy implies.
Reading the Crack Time Table
The crack time table in the tool displays two fundamentally different threat models, and the difference between them spans many orders of magnitude. GPU rows assume the attacker has obtained a password hash from a database breach and is cracking it offline with dedicated hardware. Online rows assume the attacker is submitting guesses against a live login service where network latency and rate limits apply.3
GPU Fast Hash (NTLM, MD5)
Fast hash algorithms like NTLM and MD5 are non-iterative. Engineers originally optimized these algorithms for raw execution speed, which makes them catastrophic when a hash database leaks. Public hashcat benchmark threads show the scale: an RTX 4070 Ti Super reported 133.2 GH/s for NTLM, an RTX 5070 reported 94.9 GH/s, an RTX 4090 reported 285.8 GH/s, and an RTX 5090 thread reported about 300 GH/s.4 Against a fast hash, those numbers explain why short or patterned passwords are dangerous; a truly random 12-character full-ASCII string still has an exhaustive keyspace far beyond one GPU, but real attackers rarely brute force that full space.
GPU Slow Hash (bcrypt cost 12 / Argon2id)
Conversely, slow hash functions like bcrypt and Argon2id are intentionally engineered to defend against this massive hardware scale. The same benchmark threads show bcrypt at cost factor 5 around 99.9k H/s on the RTX 4070 Ti Super, 85.1k H/s on the RTX 5070, 239.6k H/s on the RTX 4090, and about 307.8k H/s on the RTX 5090. Scaled to bcrypt cost factor 12, those figures become roughly 780 H/s, 665 H/s, 1,872 H/s, and 2,405 H/s. That speed difference, from hundreds of thousands to hundreds or thousands, is why security engineers insist on slow hashing for stored credentials. OWASP describes work factor as usually 2^work iterations and currently recommends Argon2id for new systems, with bcrypt cost factor 10 or more for legacy systems.5
Online Attack Scenarios
Online rows use zxcvbn’s pattern-aware guess estimate rather than raw brute force. Attackers hitting a live login endpoint start with common passwords and credential-stuffing lists rather than random combinations. While a throttled scenario limits attempts to 100 guesses per hour via rate limiting, unthrottled servers face a relentless onslaught of 10 hits per second. Because automated credential-stuffing tools cross-reference live endpoints against massive pre-compiled breach databases, any password containing common patterns will fall rapidly unless the service enforces strict rate-limiting safeguards.
The takeaway is straightforward: hash algorithm choice matters more than password length for offline attacks. A predictable 14-character password hashed with MD5 can fall faster than a shorter password protected by a slow, properly configured password hash. When you control the hash function, pick a slow one. When you don’t, length and randomness are your only leverage.
Practical Password Strategies Based on Entropy
Length beats complexity. A 20-character all-lowercase passphrase has approximately 94 bits of entropy, more than an 8-character full-ASCII password at 52.5 bits. The math is simple: each additional lowercase character adds 4.7 bits, and those bits accumulate faster than pool expansion does for short strings. A passphrase like correct horse battery staple carries more real-world strength than K9#mP2!x despite looking less impressive.
Where you add entropy matters as much as how much you add. Focus on these principles when building passwords:
- Place new character classes in early positions, not predictable suffixes
- Avoid date suffixes: four-digit years only add 13.3 bits at most.
- Skip
l33tspeak substitutions like@foraor$fors, since cracking rules apply these automatically - Never append
123,!, or sequential digits to the end of a word - Use a passphrase of four or more random words instead of a short complex string
The best way to internalize these principles is to test real candidates against the tool. Type a draft password, check which of the five pattern categories zxcvbn flags, fix the weakness, and re-check. Each round sharpens your intuition for what the model catches, and after a few cycles you can spot predictable structures before you even hit enter.
Using the Tool Iteratively to Build Better Passwords
To put these rules into practice, treat password selection as an interactive validation loop rather than a single guessing game. Here is how that loop works with the Password Entropy Analyser:
- Draft a candidate password
- Type it into the analyser and read both the entropy score and the zxcvbn pattern feedback
- Fix whatever the feedback flags: replace dictionary words, break up keyboard walks, remove sequential runs
- Re-check and repeat until both signals agree the password is strong
That specificity is what makes the tool useful for learning, not just grading. Instead of a generic “weak” label, zxcvbn names the exact structural flaw, so you know precisely what to change next time.
The analyser works offline after the initial page load, which makes it practical for air-gapped environments or untrusted networks. Load the page on a trusted connection, disconnect, and then evaluate passwords with full confidence that nothing leaves the machine. For security professionals conducting audits or developers testing credential policies against NIST SP 800-63 guidance, that offline capability isn’t a convenience. It’s a requirement.6 Sending production passwords through a third-party meter, even an encrypted one, violates the principle of least exposure.
The gap between perceived strength and actual entropy is where most credential failures live. By relying on predictable substitutions and recognizable keyboard patterns, users unwittingly present low-hanging targets to modern cracking clusters, no matter how complex the string looks at a glance. Closing that gap means abandoning visual complexity as a proxy for security and treating entropy as what it actually measures: the number of guesses an attacker must burn through before your secret collapses.
- 1.
Physics LibreTexts, “1.3: Entropy and Probability,” phys.libretexts.org, accessed June 2026. https://phys.libretexts.org/Bookshelves/Thermodynamics_and_Statistical_Mechanics/Book%3A_Thermodynamics_and_Statistical_Mechanics_(Arovas)/01%3A_Fundamentals_of_Probability/1.03%3A_Entropy_and_Probability
- 2.
Dropbox, “zxcvbn,” github.com, accessed June 2026. https://github.com/dropbox/zxcvbn
- 3.
NIST, “Strength of Passwords,” SP 800-63-4, nist.gov, accessed June 2026. https://pages.nist.gov/800-63-4/sp800-63b/passwords/
- 4.
hashcat, “RTX GPU Benchmark Threads,” hashcat.net, accessed June 2026. https://hashcat.net/forum/thread-12051.html; https://hashcat.net/forum/thread-13327.html; https://hashcat.net/forum/thread-11277.html; https://hashcat.net/forum/thread-12487.html
- 5.
OWASP Foundation, “Password Storage Cheat Sheet,” github.com, accessed June 2026. https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md
- 6.
NIST, “Digital Identity Guidelines: Authentication and Lifecycle Management,” SP 800-63B, nist.gov, June 2017. https://pages.nist.gov/800-63-3/sp800-63b.html
