Password Entropy Analyser

Why offline analysis matters

Typing a password into a web-based strength meter is a small act of trust most people make without thinking. When the meter runs server-side, the password travels over HTTP before any feedback appears. The security check itself becomes a data exposure event. This tool works differently: analysis runs entirely in your browser using TypeScript and a pattern model that loads locally as a JavaScript module. Nothing is transmitted.

The pattern analysis library loads on demand the first time you click the input field, not at page load. Your browser caches those module files, and after that initial download, every analysis runs in local memory. You can verify this yourself by opening DevTools, switching to the Network tab, and typing a password. The only requests shown are the module files loading once. After that, there are no outbound requests, and the tool continues working even offline.

Shannon entropy and character pool size

Entropy is a measure of unpredictability, not complexity. It counts the bits of uncertainty an attacker must resolve to guess your password through brute force, under the assumption that they know your character set but not which specific characters you chose. Adding even one character class expands the keyspace significantly, because the attacker must now test every position against a larger alphabet.¹

Pool size comes from which character classes appear: lowercase letters add 26, uppercase adds 26, digits add 10, and printable ASCII symbols add 33, giving a maximum pool of 95. Entropy equals length multiplied by log₂(poolSize). A 12-character password using the full 95-character set yields roughly 78.9 bits, meaning an attacker must resolve 2⁽⁹·⁹ possible combinations to guarantee a hit. Using even one uppercase letter grants the full 26-character uppercase pool, because a brute-force scanner must test every position against the expanded alphabet.²

What entropy does not capture

High entropy does not mean a password is strong in practice. Entropy treats every character position as equally random, but humans rarely choose randomly. A 15-character all-digit password carries 49.8 bits of entropy by the formula, yet every character is drawn from a pool of only 10. An attacker targeting digit-only combinations exhausts that space far faster than the entropy figure implies. The tool accounts for this by capping the displayed strength score using both zxcvbn's pattern estimate and the entropy ceiling simultaneously, always showing the lower of the two signals.³

How long is long enough

Band arithmetic gives length targets. Eight full-pool characters carry about 52.6 bits, inside the Fair band; twelve carry about 78.9 bits, into Strong; sixteen carry about 105 bits, far past the top band. Each added character multiplies the brute-force space by the pool size, which is why one more character moves the bands faster than adding an entire character class: a longer string drawn from a smaller alphabet routinely outscores a shorter one decorated with every symbol on the keyboard. The formula in the paragraphs above does the exact arithmetic for any length you are weighing.

The PIN is the anti-example. A four-digit PIN carries 13.3 bits of entropy and a six-digit PIN 19.9 bits, both deep in the Very Weak band, and both survive on phones and bank cards only because the device throttles guesses. Throttling is an online-attack defense; it does nothing for a stolen hash, where the table's fast-hash rows clear the entire four-digit space almost instantly. The meter reports the raw number honestly either way, which is the right behavior for an analyser: your threat model, not the score band, decides whether 13 bits is acceptable.

The math holds only when each character is drawn unpredictably, which is what a cryptographic random source provides and what human choice does not. Hand-picked strings carry exactly the patterns the pattern section catalogs: dictionary words, walked keyboards, appended years. The honest workflow is to generate from a secure source, paste the result here to confirm the score, and adopt it only when both signals agree. A password you composed yourself has already been shaped by the memorable habits every cracker exploits first, no matter how many character classes it spans.

What the NIST guidelines require

The rules themselves are short. The current guidance requires verifiers to demand at least 15 characters when a password authenticates on its own, and at least 8 when it only backs a second factor; it calls for accepting passwords of at least 64 characters, including every printing ASCII character and the space; it prohibits composition rules that mandate mixtures of character classes; and it prohibits forcing periodic changes unless the password shows evidence of compromise.⁴ Length is the lever the standard pulls, and each rule it drops removes a dial that never helped.

The one addition is screening. The same guidance calls for comparing every new password against a blocklist of known-compromised and commonly used values and rejecting the matches.⁵ This analyser runs entirely offline and consults no breach corpus: its dictionary matches common passwords and patterns locally, which catches the obvious end of the problem while the password stays on your machine. Full breach screening belongs to the service that stores the password, at signup or change time, because only the service can see the breached lists it checks against. A browser meter measures; a verifier screens.

Reading the meter against the rules is straightforward: the guidelines reward length and unpredictability and distrust symbol theater, which is exactly what the two signals here measure. The entropy figure prices length over the true pool; the zxcvbn score prices predictability. A password that clears the Strong band without satisfying a single composition rule is not a rebel against the standard. It is the kind of password the standard is steering you toward, and the fact that it needs no numeral, no capital, and no symbol is the point rather than the problem.

Reading the crack time table

Two separate threat models drive the table's layout. GPU rows assume the attacker has obtained a password hash from a database breach and is cracking it offline using dedicated hardware with no request rate limit. Online rows assume the attacker is submitting guesses directly against a live login service, where network latency, HTTP overhead, and lockout policies slow everything down. The time scales differ by many orders of magnitude between the two categories.

For GPU rows, crack time uses raw brute force: the full keyspace (poolSize raised to the power of length) divided by 2 for the average case, then divided by the GPU's hash rate. The fast hash section covers NTLM and MD5, which are non-iterative algorithms designed for speed. Modern graphics cards test hundreds of billions of these per second. The slow hash section covers bcrypt and Argon2id, which are intentionally expensive functions that cap GPU throughput in the hundreds or thousands per second regardless of hardware tier.⁶⁷

Why bcrypt cost factor changes everything

The slow hash rows hinge on a number that never appears in the password itself: the cost factor. bcrypt repeats its internal key-setup loop a number of times set by that factor, and each step up the scale doubles the work, so a hash stored at cost 12 takes 128 times longer to test than one stored at cost 5. Hashcat benchmarks bcrypt at cost 5 by default, which is why raw benchmark charts show an RTX 4090 reaching 200,000 hashes per second.⁸ Most real login systems should not store passwords that cheaply.

Because OWASP's current guidance prefers Argon2id for new systems and lists bcrypt as a legacy fallback with a work factor of 10 or more, the table models bcrypt at cost 12 as a conservative legacy setting. Published hashcat v6.2.6 benchmarks measure the RTX 4090 at 184 kH/s at cost factor 5, and dividing by 128 lands at the table's 1,440 H/s at cost 12. The size of the difference is easiest to feel in concrete numbers: a 12-character digits-only password clears the 4090's NTLM row in about two seconds yet needs about eleven years against its bcrypt row, while a 12-character full-pool random password survives millennia on both rows. The algorithm a site chooses, and the cost factor it configures, shapes your real exposure far more than the raw speed of the attacker's card.

Online rows use zxcvbn's pattern-aware guess estimate rather than raw brute force. Attackers hitting a live login endpoint start with the most common passwords and credential-stuffing lists, not random combinations. A password that looks random to a brute-force formula might still fall quickly if it follows a recognizable pattern that appears in breach data. Throttled means 100 guesses per hour, which most web services enforce. Unthrottled means 10 guesses per second on a service with no rate limiting configured.³

zxcvbn pattern analysis

Most passwords people create fall into patterns that attackers specifically train for. NIST notes that attackers are likely to guess dictionary words and passwords from previous breaches, so common patterns should be blocked before throttling takes effect.⁵ zxcvbn applies the same idea locally: it starts with common passwords and wordlists, then applies systematic mutations and character substitutions. The pattern label in the metric strip identifies the dominant structure found in your password, if any. Five categories cover the most common weaknesses:

The five weakness categories

• Dictionary: matched a common English word, name, or well-known password pattern.
• Keyboard walk: follows adjacent key rows or columns such as "qwerty", "asdfg", or "1qaz2wsx".
• Repeated characters: "aaaa", "abababab", or other repeating substrings.
• Sequential characters: consecutive alphabet or number sequences such as "abcd", "1234", or "zyxw".
• Date pattern: embedded dates in common formats like "19870612" or "Jun1987".

When Shannon entropy and the zxcvbn score point in different directions, the tool always applies the lower of the two. "P@$$w0rd123" 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. Your final displayed score reflects both signals, and the feedback panel explains exactly what zxcvbn detected and how to address it.

Where passphrases fit

A passphrase's bits come from the word list it draws from. Each uniformly random word contributes log₂(listSize) bits, so five words from a 7,776-word list carry about 64.5 bits, comparable to a ten-character full-pool random string, and six words clear 77 bits, into the Strong band.⁹ The arithmetic is friendlier than character math because words are chunky: on the standard dice wordlist each added word buys the same fixed block of uncertainty, roughly 12.9 bits, without a single symbol to remember or type.

The words must be selected at random, by dice or a generator, not lifted from a famous quote or a sentence you would actually say. zxcvbn scores dictionary-on-dictionary matches far below their raw bit count, because attackers test phrase-shaped guesses early. The meter distinguishes the two cases, holding a genuinely random word sequence near its arithmetic while collapsing a memorable sentence into pattern matches. That split is the whole reason both signals run side by side here: entropy prices the words, and the pattern engine prices the way you picked them.