Password Entropy Analyser Reference

12-Character Password Entropy

Twelve characters used to be the gold standard. Shannon entropy for a password of this length depends entirely on which character classes you draw from, not just the count itself.¹ And that dependency is where most confusion starts. A lowercase-only twelve-character password carries roughly 56.4 bits of entropy, because each position is chosen from a pool of just 26 letters. Add uppercase, digits, and the full range of printable symbols, however, and the same twelve positions climb to close to 78.8 bits, since every position now draws from a 95-character pool instead of 26. Consequently, two twelve-character passwords can sit worlds apart in resistance to brute force despite looking equally 'long' at a glance. This page walks through the exact calculation behind each figure, shows how those bits translate into GPU crack-time estimates, and explains where twelve characters lands against current NIST length guidance.

What is 12-character password entropy?

How character pool size swings 56.4 bits into 78.8 bits

Pool size, not raw character count, drives most of the swing in a twelve-character password's entropy score. Lowercase-only passwords draw from 26 possible characters per position, so twelve positions yield 26¹² possible combinations, or about 56.4 bits once converted through log₂, making the contrast between constrained and full-pool passwords starkly visible in the final bit count. Mixing in uppercase doubles the pool to 52, adding roughly 12 bits total across the full string. Digits push the pool to 62 characters, and the full printable ASCII range, including symbols like !, @, and #, pushes it to 95.

Why hitting the full pool matters in practice

Because entropy grows with the logarithm of pool size rather than linearly, each expansion delivers a shrinking return: moving from 26 to 52 characters adds about 12 bits, but moving from 62 to 95 only adds roughly 7.4 bits across the same twelve positions. Length still matters more than any single pool expansion. Yet combining full pool size with adequate length is what actually closes the gap between a merely long password and one that is genuinely hard to guess.

What 78.8 bits means against a modern GPU

A twelve-character password drawn from the full 95-character pool creates a keyspace of roughly 2⁷⁸·⁸, or about 5.25 × 10²³ possible combinations. Cracking a leaked NTLM hash offline on a single RTX 4090, benchmarked at roughly 300 GH/s, means an attacker faces an average-case search of half that keyspace.³ Dividing the expected 2.6 × 10²³ guesses by that hash rate works out to somewhere on the order of tens of thousands of years, even running dedicated consumer hardware continuously.

Why bcrypt changes the picture entirely

That estimate assumes a fast, non-iterative hash like NTLM. Store the same password with bcrypt at cost factor 12 instead, and the RTX 4090's throughput drops to roughly 1,560 hashes per second³, because bcrypt is deliberately expensive to compute by design.⁴ At that rate, the same twelve-character password would take roughly 400 times longer to crack than the current age of the universe. The hashing algorithm a service chooses, not just your password's raw entropy, decides how meaningful these numbers actually are in practice.

None of this changes the keyspace itself. A twelve-character password from the full 95-character pool still has roughly 2⁷⁸·⁸ combinations. What changes is what an attacker can afford to try. Without a slow hash, each guess is cheap enough to run billions per second on consumer hardware, so entropy alone is no longer enough to protect a leaked secret. With bcrypt in place, the attacker must pay a fixed cost for every single guess, and that cost is what turns a mathematically impressive bit count into an actually uncrackable password in practice.

Where 12 characters sits against NIST's current guidance

NIST's SP 800-63-4 guidance draws a hard line at length rather than complexity. Passwords standing alone as a single authentication factor SHALL be at least fifteen characters; passwords used only as part of multi-factor authentication SHALL be at least eight.⁵ Twelve characters sits comfortably above the multi-factor floor but a full three characters under the single-factor recommendation, which matters more than it might first appear.

Closing the gap without memorizing more

Stretching from twelve to fifteen characters at the full 95-character pool moves entropy from about 78.8 bits to roughly 98.5 bits, a jump that outpaces almost anything achievable by adding character classes alone. Because NIST also discourages composition rules and instead recommends screening against known breached passwords, the practical move is to lean on a password manager's generator for the extra length rather than inventing more complexity by hand. Length, consistently, does the heavier lifting.

Try in the tool

16-Character Password Entropy

Four extra characters buy more than most people expect. Stretched to sixteen characters, a full-pool password crosses 105 bits of Shannon entropy¹, comfortably past the ninety-eight bits a fifteen-character password reaches and well clear of the length NIST now recommends for a password carrying single-factor authentication on its own². Even at a reduced 62-character pool, using only upper, lower, and digits, sixteen positions still deliver roughly 95.3 bits. Because entropy compounds with every additional position rather than adding a fixed amount, the difference between a twelve-character and a sixteen-character password is far larger than the four extra keystrokes suggest. This page works through the exact bit counts across common pool sizes, shows what those numbers mean against real GPU cracking benchmarks, and explains why sixteen characters is treated as a practical ceiling for manually memorized passwords rather than a floor.

What is 16-character password entropy?

From 78.8 bits to 105.1 bits: the cost of four more characters

A twelve-character password from the full 95-character pool tops out at about 78.8 bits. Stretching the same pool to sixteen characters does not add a proportional 33% more bits; it adds four entire multiplications by 6.57, pushing the total to roughly 105.1 bits. That gap of 26.3 bits corresponds to a keyspace more than 80 million times larger, because entropy measures an exponent rather than a linear count.

For context, moving from a 62-character pool to the full 95-character set at twelve characters adds only about 7.4 bits, similar to what four extra characters alone deliver at the smaller pool. Consequently, once you are already drawing from a wide character pool, adding length outperforms adding more symbol variety almost every time.

When four characters outperform every composition rule

Longer full-pool passwords consistently outperform adding character variety to shorter ones. Adding four characters at the 95-character pool contributes roughly 26.3 bits across twelve positions, while expanding from a 62-character pool to 95 at twelve positions adds only about 7.4 bits. That gap is why password managers recommend longer generated passwords as the most reliable way to raise entropy. From a user standpoint, that recommendation means you get a much bigger security gain from asking your generator for a few more characters than you do from manually inserting symbols into a shorter password, because each extra character multiplies the total keyspace while symbol swaps only expand it once.

Why 105 bits makes the hashing algorithm almost irrelevant

At 105.1 bits, the keyspace behind a sixteen-character full-pool password reaches roughly 4.4 × 10³¹ combinations. Even against the fastest fast-hash GPU benchmark on the main entropy tool page, an RTX 5090 running NTLM at roughly 340 GH/s, exhausting half that keyspace on average would take on the order of a trillion years.³ Because that timeframe already dwarfs the age of the universe by many orders of magnitude, the difference between a fast hash like NTLM and a slow hash like bcrypt barely matters at this length. The practical takeaway is that entropy at this scale already outpaces any realistic offline attack, regardless of how much hashing throughput an attacker can afford.

When length alone stops being the deciding factor

That does not make the hashing algorithm choice irrelevant everywhere. Shorter, human-chosen passwords still depend heavily on whether a service uses bcrypt or Argon2id, since those algorithms are the difference between a crackable password and an uncrackable one at moderate entropy.⁴ At sixteen full-pool characters, though, length has already done the job that a slow hash would otherwise need to do.

That crossover is exactly why password managers default to longer generated passwords: once entropy crosses roughly 100 bits, the password itself has already outrun any realistic offline attack⁵, so the hashing algorithm becomes a secondary concern rather than the primary defense line. That approach keeps the focus on what actually matters for users: choosing a length that makes brute force impractical no matter how the password is stored.

Sixteen characters against NIST's length guidance

NIST SP 800-63-4 sets fifteen characters as the SHOULD-level recommendation for passwords used as a single authentication factor, alongside a SHOULD-level maximum of at least sixty-four characters that verifiers must permit.⁶ Sixteen characters clears that recommendation by one position, which is a comfortable but not excessive margin. Because the guidance also drops mandatory composition rules, a sixteen-character password does not need mixed character classes to satisfy the recommendation, only sufficient length.

Where the extra margin actually helps

The one-character buffer above fifteen matters most when a service enforces a slightly different internal minimum, or when you want headroom for future guidance revisions without needing to change your habits again. For anyone using a password manager's generator, defaulting to sixteen characters at the full pool costs nothing extra to type and removes the question of whether you are exactly at the recommended floor or one character short of it. Because entropy at this length already exceeds what any realistic offline attack could meaningfully dent, treating sixteen as your default rather than the bare fifteen-character minimum removes any doubt about whether a specific service's internal policy has actually been satisfied.

Try in the tool

4-Digit PIN Entropy

Thirteen point two nine bits sounds precise, and it is, but it describes an assumption that rarely holds for real PIN codes. A four-digit PIN drawn from the digits 0 through 9 has a pool of just 10 possible values per position, giving 10⁴, or 10,000, total combinations and log₂(10,000) ≈ 13.29 bits of entropy under the standard formula.¹ That number assumes every one of those 10,000 combinations is equally likely to be chosen. In practice, people do not pick PINs uniformly at random; birthdays, repeated digits, and simple sequences dominate real-world choices by a wide margin. This page works through the formal entropy calculation, then shows how badly a uniform-distribution assumption misrepresents the actual security of a typical human-chosen four-digit PIN.

What is 4-digit PIN entropy?

The math behind 13.29 bits

Every digit position in a four-digit PIN can independently take one of 10 values, so the total keyspace is 10 × 10 × 10 × 10, or 10,000 combinations. Converting that count to bits through log₂ gives roughly 13.29, a figure small enough that brute-forcing every combination takes a computer well under a second. For comparison, a randomly generated eight-character password from the full printable ASCII set carries roughly 52.6 bits, over a billion times more combinations than a four-digit PIN. That same bit scale is what makes both inputs directly comparable, whether you are scoring a PIN, passphrase, or generated password.

Why these two inputs look so different on paper

Both a four-digit PIN at roughly 13.29 bits and an eight-character password from the full printable ASCII set at roughly 52.6 bits sit on the same bit scale. The comparison between them is meaningful because the bit-based output is what makes inputs of completely different lengths and character pools directly comparable, and it is the same scale every entropy checker uses when it reports a numerical strength score.²

Because the keyspace is so small in absolute terms, a four-digit PIN only stays practical as a security measure when something outside the PIN itself limits how many guesses an attacker can try. Rate limiting, lockouts, and hardware-enforced delays do that job; the PIN's own entropy cannot. That enforcement turns a 10,000-combination keyspace into a practical deterrent rather than a purely theoretical one.

Why real PINs carry far less than 13.29 bits

An analysis of roughly 3.4 million leaked four-digit PINs found that '1234' alone accounted for about 10.7% of all choices, with '1111' at roughly 6.0% and '0000' at about 1.9%.³ Just the top 20 most common PINs covered nearly 26.8% of the entire dataset. Consequently, the effective entropy of a human-chosen PIN, calculated from its actual probability of selection rather than a uniform assumption, sits far below the theoretical 13.29-bit ceiling.

What the skew means for an attacker

An attacker who tries the twenty most common PINs first, rather than guessing randomly, has better than a one-in-four chance of succeeding before exhausting even 0.2% of the total keyspace. This is exactly the gap zxcvbn is designed to catch in longer passwords: raw entropy assumes randomness, and human choices are rarely random, so pattern-aware analysis matters more than the bit count alone.²

The practical consequence is that the Shannon bit count only describes a perfect random draw. Once a real person is involved, the bit count becomes a ceiling rather than a typical value, and the security a user actually gets depends far more on how unique their choice is than on the 13.29 figure they see in a tool.

Where a 4-digit PIN is still an acceptable choice

A four-digit PIN remains workable specifically because most systems that use one, phone lock screens, ATM cards, door entry pads, pair it with strict throttling rather than relying on the PIN's entropy alone. Three to five failed attempts typically trigger a lockout or an escalating delay, which turns a 10,000-combination keyspace into a meaningfully hard target even though the raw entropy is tiny by password standards.⁴

Why the top-20 list still matters under throttling

Avoiding the most common patterns still matters even under throttling, since an attacker with physical access to your device is effectively guessing from that top-20 list first. Skipping birthdates, repeated digits, and simple runs like '2580' or '0852' (both common because of their layout on a numeric keypad) closes most of the realistic attack surface a short PIN faces.

Most phones also pair the PIN with biometric unlock, a fingerprint or face scan that handles day-to-day access while the PIN sits in reserve as a fallback. That pairing does not raise the PIN's own 13.29-bit ceiling, but it does reduce how often the PIN itself gets typed in the open, which lowers the chance of shoulder-surfing capturing it in the first place. A device that has never asked for the PIN outside a controlled setup screen offers an attacker far fewer opportunities to observe it being entered.⁵

Try in the tool

6-Digit PIN Entropy

Apple switched the iPhone's default passcode from four digits to six back in iOS 9, and the arithmetic behind that change looks compelling at first glance.¹ A six-digit PIN draws from the same 10-digit pool as a four-digit one, but two extra positions multiply the keyspace to 1,000,000 combinations, or 19.93 bits of Shannon entropy², a hundred times larger than a four-digit PIN's 13.29 bits. On paper, that is a clear win. In practice, research into how people actually choose six-digit PINs tells a more complicated story, one where the extra digits often buy far less real-world protection than the bit count implies. This page covers the formal math, then the field research that shows why six digits is not simply 'four digits, but better.'

What is 6-digit PIN entropy?

The math: a 100-fold larger keyspace

Two extra digits multiply, rather than add to, the total combination count. Four digits yield 10⁴ combinations; six digits yield 10⁶, exactly one hundred times more. Converted to bits, that hundredfold jump corresponds to log₂(100) ≈ 6.64 additional bits of entropy, taking the total from 13.29 to 19.93. Against an attacker limited to a fixed, small number of guesses, a hundredfold larger keyspace should mean a hundredfold lower chance of a lucky hit within that guess budget. This is exactly why the bit difference between 13.29 and 19.93 looks more impressive on paper than it behaves in practice: the hundredfold keyspace only protects against unlimited guessing, but most real devices enforce guess limits long before brute force ever reaches the millionth combination.

That logic holds only if every combination in the larger keyspace is equally likely to be chosen, the same uniform-distribution assumption that already fails for four-digit PINs. This logic also overlooks how people actually choose PINs, which is where the real security gap appears after six digits. Whether it also fails for six-digit PINs is an empirical question, and researchers have specifically studied it.

Where six digits land on the entropy scale

A six-digit PIN landing at 19.93 bits sits above a four-digit PIN at 13.29 bits, but still far below even a moderately chosen password³. The point of comparing those figures is not to declare six digits perfectly strong. It is to show where that strength sits relative to other inputs CapyToolkit measures and how much of the apparent advantage vanishes once human choice patterns enter the picture. The same comparison pattern appears elsewhere in password entropy analysis: a convincing bit count on paper, and a very different story once actual user behavior replaces the uniform-random assumption.

Why the extra two digits barely help against real attackers

A widely cited study of smartphone unlock PINs found that against a throttled attacker limited to 10, 30, or 100 guesses, matching typical phone lockout policies, six-digit PINs provide little to no security improvement over four-digit PINs, and in some cases perform worse.⁴ Follow-up research analyzing PIN datasets found that 29.63% of six-digit PINs follow a DDMMYY date format and 20.66% follow MMDDYY, meaning roughly half of all six-digit PINs studied encode a calendar date.⁵

Why date-shaped PINs concentrate the keyspace

Because six digits happen to match a common date format exactly, people gravitate toward birthdays and anniversaries instead of using the extra length to pick something less predictable. An attacker who prioritizes date-shaped guesses over the full 1,000,000-combination space effectively faces a keyspace closer to a few thousand plausible dates, undoing most of the theoretical hundredfold gain over four digits.

The concentration mirrors what happens with four-digit PINs, just at a larger scale: the format constraint funnels human choices into a far smaller effective space than the raw keyspace implies. A date-shaped six-digit PIN is therefore not a weaker random six-digit PIN; it is a structured answer to a six-position numeric question, and structure is exactly what an attacker exploits first before falling back to broader guessing. The result is a deceptively small practical keyspace sitting inside the mathematical 19.93-bit ceiling.

When the extra two digits genuinely matter

The hundredfold keyspace increase still counts for something in scenarios where an attacker is not limited to a handful of throttled guesses. Offline attacks against a PIN-derived encryption key, or a device with a bypassed or absent lockout mechanism, expose the full 1,000,000-combination space rather than the effective guess budget a lockout policy enforces³. In those cases, the gap between 13.29 and 19.93 bits translates directly into a hundredfold longer brute-force effort.

Capturing the hundredfold gain in practice

The practical takeaway is not that six digits are worthless, but that the security a PIN provides comes primarily from throttling and lockout enforcement, not from the extra keyspace, unless you also avoid the date-shaped patterns researchers found to be so common. Choosing a six-digit PIN that is not a date, and is not a simple repeated or sequential pattern, is what actually captures the theoretical hundredfold improvement.

A useful test is whether your six digits would still look random if someone rearranged them. A PIN built from a birthday still contains a valid month and day pairing no matter how you reorder it, which is exactly the kind of structure a smart attacker checks for before falling back to brute force across the full million-combination space.

Try in the tool

Diceware Passphrase Entropy

Twelve point nine two five: that exact number of bits is what every word contributes when you build a passphrase from the EFF's Diceware wordlist, provided you pick each word with genuine randomness rather than free association. The wordlist itself contains 7,776 words, chosen because 7,776 equals 6⁵, the number of possible outcomes from rolling five standard six-sided dice.¹ Each dice roll selects one word, and because that selection is uniformly random across all 7,776 entries, every word adds exactly log₂(7776) ≈ 12.925 bits regardless of which word gets picked.² Unlike a memorized password built from character substitutions and familiar patterns, a properly rolled Diceware passphrase carries entropy you can calculate with certainty rather than estimate. This page explains where the 12.9-bit figure comes from, how many words you actually need, and how a word-based passphrase compares to a character-based password of similar strength.

What is Diceware passphrase entropy?

Where 12.9 bits per word actually comes from

Diceware's design ties directly to physical dice. Rolling five six-sided dice produces 6⁵, or 7,776, distinct outcomes, and the EFF built its wordlist to contain exactly that many entries so each five-roll sequence maps to one word.¹ Because every word in the list is equally likely to be selected by a fair set of dice, log₂(7776) gives the exact, guaranteed entropy contribution of each word: approximately 12.925 bits.³

That guarantee is the entire point of using dice instead of picking words from memory. A human trying to think of a 'random' word gravitates toward common, short, emotionally resonant choices, which collapses the effective entropy far below 12.9 bits per word. Physical randomness, or a cryptographically secure random number generator standing in for it, is what makes the math hold.

Why picking words from memory breaks the calculation

Physical randomness is not just a preference; it is the only way the 12.9-bits-per-word guarantee survives contact with human selection. When someone chooses words that feel memorable or thematically related, the effective pool of choices shrinks to a small fraction of 7,776. That collapse is exactly what makes the entropy of a human-chosen passphrase fall so far below the theoretical value Diceware was built to provide.

How many words you need, and what that buys you

The EFF recommends a six-word passphrase for most uses, landing at roughly 77.5 bits of entropy, a figure that sits close to the 78.8 bits a twelve-character password draws from the full 95-character printable ASCII pool.⁴ That similarity is not a coincidence so much as a useful reference point: six random dictionary words and twelve fully random characters land in roughly the same security tier, despite looking completely different to type and remember.

Comparing words to characters at equal strength

Where the two diverge is usability. Six words separated by spaces are far easier to type without transposition errors and far easier to recall correctly than twelve characters drawn from ninety-five possible symbols, uppercase and lowercase letters, digits, and punctuation combined. Adding a seventh word pushes a passphrase to roughly 90.5 bits, comfortably exceeding even the full-pool entropy of a fifteen-character NIST-recommended password⁵, while adding only one more easy-to-remember word rather than three harder-to-remember characters.

The trade becomes obvious when you compare both inputs through a scoring system rather than by character count alone. A twelve-character password with mixed case, digits, and symbols is harder to type and recall correctly than six dictionary words, yet both can reach roughly the same entropy target. The passphrase keeps the selection process simple while still occupying a high-entropy tier.

Why genuine randomness is non-negotiable

The 12.9-bit-per-word figure only holds when word selection is truly uniform across the full 7,776-entry list. A passphrase assembled by picking words that feel memorable or thematically related draws from a far smaller effective pool, because predictable word associations are exactly the kind of pattern that dictionary-and-mutation attacks are built to exploit.³ This mirrors the same gap that makes a human-chosen character password weaker than its raw Shannon entropy suggests.

Removing the risk with dice or a secure generator

Using physical dice, or a tool that draws from a cryptographically secure random source, removes that risk entirely. Because each word's selection is independent of every other word in the phrase, there is no shortcut for an attacker beyond testing the full keyspace, which is exactly what the 12.9-bits-per-word figure is designed to guarantee. A password manager's built-in passphrase generator typically automates this dice-rolling step for you, drawing from the same wordlist through a secure random source rather than requiring you to physically roll and record five dice per word.

Try in the tool

WPA2 Wi-Fi Passphrase Entropy

Eight and sixty-three: those two numbers bound every WPA2 Wi-Fi passphrase you will ever type, a range fixed directly by the IEEE 802.11 standard rather than by any particular router's firmware. WPA2-Personal and WPA3-Personal both accept a passphrase of 8 to 63 printable ASCII characters, codes 32 through 126, the same 95-character pool used elsewhere on this tool.¹ At the 8-character minimum with the full pool, that gives roughly 52.6 bits of entropy; at 63 characters, the number climbs past 400 bits, far beyond anything a brute-force attack could realistically approach.² Yet the passphrase itself is never used directly as the encryption key. WPA2 runs it through a specific key-derivation function first, and understanding that pipeline changes how you should think about passphrase strength.

What is WPA2 Wi-Fi passphrase entropy?

Why WPA2 never uses your passphrase directly

Your typed passphrase is not the encryption key. WPA2 feeds it into PBKDF2-HMAC-SHA1, running 4,096 iterations with your network's SSID acting as the cryptographic salt, to derive a fixed 256-bit Pairwise Master Key regardless of passphrase length.¹ Consequently, a longer passphrase does not produce a longer or stronger key; it produces the same 256-bit output through a computation that is far more expensive to repeat than a single hash lookup. That fixed output length is what separates WPA2 passphrases from raw entropy figures: the entropy still matters for choosing a strong input, but it does not change the size of the derived key. The clarity matters because the same numeric entropy figure that looks encouraging on a password can look misleading when applied to a Wi-Fi passphrase, since the key underneath is always the same length.

What 4,096 iterations buys you

That iteration count works the same way a slow hash like bcrypt protects a stored password: it multiplies the cost of every guess an offline attacker makes against a captured handshake.³ A passphrase's real resistance to cracking comes from combining that computational cost with enough entropy that guessing correctly, even slowly, stays impractical. Raising the iteration count is exactly why current Wi-Fi recommendations treat 4,096 as a minimum: it multiplies the cost of every offline guess without making legitimate logins feel slower to a person typing a passphrase. That trade-off between login latency and crack resistance is what makes the iteration choice a security parameter rather than just a performance one.

The same trade reappears whenever a tool or service protects sensitive data with deliberate slowness, and it is useful to recognize that iteration tuning does not try to prevent all guessing; it tries to make each guess expensive enough that offline cracking remains impractical. That distinction between preventing guesses and making them costly is what separates password hashing from encryption, because hashing is designed to degrade gracefully under attack rather than to hide the underlying data once computation time falls.

Where a long passphrase fits on the entropy scale used by the tool

A 63-character passphrase from the full 95-character pool rises above 400 bits of raw Shannon entropy, yet the underlying key is still only 256 bits. CapyToolkit uses that gap deliberately when it scores passphrase length: the advantage of adding more characters is real in the brute-force sense, but it is bounded by what the derivation function ultimately produces rather than by whatever the bit formula predicts.

How passphrase length changes practical crack resistance

Because PBKDF2's iteration count applies equally regardless of passphrase length, the entropy of the passphrase itself is what determines how many of those expensive iterations an attacker must run before finding a match.³ An 8-character minimum-length passphrase from the full 95-character pool, at roughly 52.6 bits, sits in a similar range to a random 8-character password, meaning it is vulnerable to a sufficiently patient offline attack against a captured handshake.

How choosing your own passphrase compares to a router-generated one

Router-generated default passphrases, often 10 to 12 random alphanumeric characters set by the manufacturer or ISP, typically land well above that floor because they draw from a wide character pool with genuine randomness. NIST's WLAN security guidelines reference the IEEE 802.11i standard and recommend using passphrases significantly longer than the minimum to resist offline attacks.⁴ A passphrase you choose and type yourself is only as strong as that same randomness; picking a memorable phrase or a short word-plus-number combination undermines the entropy the standard's 63-character ceiling makes available.

Because a captured handshake can be attacked entirely offline once an attacker has it, there is no throttling or lockout policy standing between your passphrase and a determined GPU cracking session. That makes Wi-Fi passphrases a case where the offline threat model applies by default, not just as a worst-case scenario, since capturing a handshake requires nothing more than a device briefly connecting to your network within radio range and does not require any special access to your router.

The SSID is the salt, and that has a real consequence

Using the SSID as the PBKDF2 salt means the same passphrase produces a different derived key on a network named 'HomeWiFi' than on one named 'Netgear47'. Attackers exploited this early on: the Church of WiFi project built precomputed hash tables covering roughly one million common passphrases against the 1,000 most popular default SSIDs, trading disk space for a thousandfold speedup against any network still using one of those names.⁵

Renaming your network away from a manufacturer default, even to something unrelated to your passphrase's actual strength, removes your network from every precomputed table built against common SSIDs. Combined with a long, randomly generated passphrase drawn from the full character pool, that closes off both the precomputation shortcut and the brute-force path at once.

Try in the tool