{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ assistiveStatus }} {{ issueMessage }}
Length Character mix
Password strength check
Enter one candidate. If multiple lines are pasted, only the first line is assessed.
{{ passwordRevealStatus }}
Optional. Separate names, handles, brands, or domains with commas.
Choose the attack situation most relevant to the password's use.
A factor of 10 divides modeled offline guessing rates by ten.
× slower
{{ assessmentExportStatus }}
SignalFindingWhy it mattersCopy
{{ row.signal }}{{ row.finding }}{{ row.note }}
Next step: {{ nextAction }}
{{ attackExportStatus }}
ScenarioGuess rateEstimated timeInterpretationCopy
{{ row.scenario }}{{ row.rate }}{{ row.time }}{{ row.note }}

These transparent rates are planning scenarios, not predictions. Real defenses, hash settings, attacker resources, and password reuse can change outcomes substantially.

{{ chartExportStatus }}

The logarithmic seconds scale keeps login and breach scenarios readable in one comparison.

Password strength is resistance to guessing, not visual complexity. A short word with a capital letter, a year, and a symbol may satisfy a composition rule while remaining near the front of an attacker's guess list. Length helps most when the added characters are unpredictable. Common words, keyboard runs, dates, repeated blocks, names, brands, and account-specific terms reduce the value of length because an attacker can model those patterns instead of trying every possible character combination.

The attack setting matters just as much as the candidate. A live login may allow only a few guesses before delays or lockout. After a database breach, an attacker can test guesses against stolen password hashes without interacting with the login page. A deliberately slow password hash raises the cost of each attempt; a fast or weakly protected hash can make billions of guesses per second plausible as a planning scenario.

Password properties and what they reveal
SignalWhat it can showWhat it cannot prove
Pattern-aware scoreHow early a candidate may appear in a realistic guessing orderThat the password is unique or absent from breach data
Composition entropyAn upper-bound search space from length and character classesThat a human-created string is random
Crack-time estimateThe effect of an assumed guess count and attack rateThe actual hardware, defenses, or time an attacker will use

A strong password should also be unique to one account. Reuse turns a compromise elsewhere into a direct credential-stuffing attempt, which a strength meter cannot detect. Password managers help by generating and storing long, distinct values, while multifactor authentication adds protection when a password is guessed or exposed. These controls complement strength estimation rather than changing a weak password into a safe one.

Testing a real secret still deserves care. A local assessment avoids sending the candidate to a remote strength service, but screen sharing, browser extensions, clipboard history, shoulder surfing, or saving the result can expose it. For an existing high-value account, it is safer to test a structurally similar dummy value and replace the real password through the account's trusted password-change flow.

How to Use This Tool:

Assess one candidate under the attack situation that best matches the account.

  1. Enter one candidate in Password. If pasted text contains several lines, only the first line is evaluated.
  2. Add names, handles, brands, domains, or project words to Known words to avoid. Separate them with commas, semicolons, or new lines so targeted patterns can be flagged.
  3. Choose a Risk lens. Use a login scenario for a live service or a stolen-hash scenario when planning for a database breach.
  4. For an offline scenario, adjust Offline slowdown factor only when the password-hashing cost is known. Then read the pattern-aware score together with the selected crack time and the strongest local signal.

Interpreting Results:

The score and selected crack time answer different questions. The score ranks guessability on a five-step scale from Very weak at 0 to Strong at 4. Crack time applies the estimated guess count to one modeled rate. A long time under a locked-down login does not make a candidate safe after a stolen-hash breach.

  • Treat a common-password, context-word, email-address, repetition, sequence, or digits-only flag as a reason to replace the candidate rather than decorate it.
  • Use composition entropy as an optimistic upper bound. For human-made passwords, the pattern-aware guess estimate carries more weight.
  • A Strong result does not check breach corpuses, reuse, account recovery, multifactor authentication, or the service's password storage.
  • Compare scenarios rather than reading a crack time as a promise. Real attacker resources and defensive settings are not known.

Technical Details:

The strength model starts with a pattern-aware estimate of guesses and a score from 0 through 4. It separately measures password length, the character classes present, and local warning patterns. The character-class calculation treats lowercase letters as 26 possibilities, uppercase letters as 26, digits as 10, and symbols as 33. That construction is useful as a transparent upper bound, not as a substitute for the pattern estimator.

Formula Core

Composition entropy assumes every character is chosen independently and uniformly from the observed character set.

Hcomposition = L×log2(N)

L is the Unicode character count and N is the combined size of the character classes present. Repeated blocks, dates, dictionary words, and keyboard sequences violate the independence assumption, so the displayed bits can be much higher than the effective guess resistance.

Crack time divides the modeled number of guesses by the chosen guess rate. Offline slowdown divides only the offline rates; it does not affect login scenarios.

log10(t) = log10(G) log10(R)

G is the pattern-aware guess estimate, R is adjusted guesses per second, and t is seconds. Durations below 0.01 seconds are shown as such; larger values move through seconds, minutes, hours, days, years, and powers of ten years.

Modeled password attack rates
ScenarioBase rateSlowdown applied
Locked-down login100 guesses/hourNo
Weakly rate-limited login10 guesses/secondNo
Stolen slow hash10,000 guesses/secondYes
Stolen fast hash10 billion guesses/secondYes
GPU cluster breach1 trillion guesses/secondYes

Rule Core

The selected verdict combines score and crack-time boundaries. Conditions are evaluated in order, so the first match controls the label.

Password verdict rules
VerdictExact condition
High risk in the selected scenarioScore ≤ 1, or crack time < 10⁴ seconds
Needs a stronger designOtherwise, score = 2, or crack time < 10⁶ seconds
Reasonable with caveatsOtherwise, score = 3, or crack time < 10⁹ seconds
Resilient in the selected scenarioNone of the earlier conditions match

Suggested extra characters use composition-entropy targets of 50 bits for a locked-down login, 60 bits for a weakly rate-limited login, 75 bits for a stolen slow hash, and 90 bits for a stolen fast hash. This recommendation is approximate because it assumes the additional characters are unpredictable. A severe local pattern flag takes priority and recommends replacing that pattern instead.

Privacy and Limitations:

The password and context words are evaluated in the browser and are not sent to a strength-checking service. The assessment does not query breach databases or store a history of tested candidates. Local processing cannot protect a secret from other software or people with access to the device.

  • Do not treat a crack-time estimate as a guarantee of survival time.
  • Do not paste a live password while screen sharing or on an untrusted device.
  • Replace reused or exposed passwords even when their local score is high.
  • Use a password manager to create a unique value and enable multifactor authentication where available.

References: