Security & devFreeNo signup
Free password strength checker. Estimate strength, entropy, and improvement tips locally in your browser. Nothing is uploaded.
Last updated 6 October 2026
If a password is the only thing between someone and your account, the United States federal guideline is no longer eight characters. NIST Special Publication 800-63B-4, published July 2025, puts it in one sentence: “Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” Eight survives only as a concession, and only where a second factor is present: the same paragraph permits passwords “only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.”
That revision superseded the 2020 edition on 31 July 2025, and it is where most of the advice on this page comes from. The bar above does not know which of those two situations you are in, and it enforces neither number. What it does compute is set out below, including the places where it disagrees with the standard it is summarising.
The panel shows a score out of 100 with a word attached, and an estimated entropy in bits. They come from different arithmetic and they can point in opposite directions.
Entropy is one multiplication. The checker inspects which kinds of character are present and adds up a notional alphabet: 26 if any lower-case letter appears, 26 more for any upper-case letter, 10 for any digit, 33 for anything else. Then it reports length × log₂(alphabet). Sixteen lower-case letters gives 16 × log₂26 = 75.2 bits. Eight characters using all four kinds gives 8 × log₂95 = 52.6 bits. Each bit doubles the number of guesses, so the 16-character string of nothing but lower-case letters is about 6.5 million times more work than the eight-character symbol soup, and far easier to type on a phone.
The score is a heuristic, and a blunter one. Length contributes three points per character but stops at 40. The number of character classes contributes twelve points each, up to 48. Reaching twelve characters adds eight, and sixteen adds eight more. A handful of penalties subtract: eight for three identical characters in a row, twelve for an all-digit string, six for letters-only under twelve characters. An exact match against a 20-entry list of very common passwords caps the total at fifteen.
Read that list again and the shape of the thing is clear: up to 48 of the 100 points are awarded for variety, and at most 56 for length. That is the opposite emphasis to the standard, which is the subject of the next two sections.
The rule that demands an upper-case letter, a digit and a symbol is the single most recognisable feature of corporate password policy, and NIST now prohibits it outright. SP 800-63B-4, section 3.1.1.2: “Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.” Section 3.1.1.1 repeats it from the other side: “Other composition requirements for passwords SHALL NOT be imposed.”
Appendix A explains why in a sentence that reads like a confession: “a user who might have chosen ‘password’ as their password would be relatively likely to choose ‘Password1’ if required to include an uppercase letter and a number or ‘Password1!’ if a symbol is also required.” The rule does not produce unpredictable passwords. It produces a narrow, predictable family of them, the same handful of shapes across an entire organisation, which is exactly what a cracking rule-set is built to expand. Appendix A closes the argument: “Length and complexity requirements beyond those recommended here significantly increase user frustration and the difficulty of using passwords. As a result, users often work around these restrictions counterproductively.”
What it recommends instead is not more rules on the user. It is work on the verifier’s side: “Other mitigations (e.g., blocklists, secure hashed storage, machine-generated random passwords, rate limiting) are more effective at preventing modern brute-force attacks.”
This is the section most strength meters leave out, including the ones that are wrong in the same way. Until 6 October 2026 the scoring here predated the July 2025 revision and contradicted it: up to 48 of 100 points came from the number of character classes present, length was capped at 40, and the result was that nothing using a single character class could be called Strong at any length. The grade now comes from the entropy shown beside it, and the two band boundaries are not numbers chosen here. They are the standard’s own length minimums, fifteen characters as a single factor and eight with a second factor, expressed in bits at the 87-character pool the generator on this site actually draws from: 96.6 and 51.5 bits. Every row below was measured by running this page’s own scoring code on 6 October 2026.
| Password | Est. entropy | This meter says |
|---|---|---|
aB3$ | 25.8 bits | Weak, 27/100 |
P@ssw0rd! | 58.0 bits | Fair, 60/100 |
Tr0ub4dor&3 | 70.9 bits | Fair, 73/100 |
correcthorsebatterystaple | 117.5 bits | Strong, 100/100 |
| 64 random lower-case letters | 300.8 bits | Strong, 100/100 |
The order of that table is now the order of the entropy column, which is the point. It did not used to be. The four-character example filled the bar to 60 per cent on the strength of its four character classes; the 64-character example, 2228 times more work to guess than the eleven-character one above it, was ranked below it. Both of those were the arithmetic working exactly as written, which is why this was replaced rather than tuned.
What the table still shows is the limit no meter can engineer away. P@ssw0rd!
appears near the top of every cracking dictionary and is called Fair here, because it is not one
of the twenty entries in the list below and nothing on this page can see a dictionary it does not
have. A grade is a statement about the shape of a string, not about whether somebody has already
guessed it. Use a generated password you do not have to remember, and the
question stops arising.
This section describes the scoring as it stands on the date in the hero above; if the scoring changes, this section is what has to change with it.
This is the limit no strength meter can engineer its way around, and NIST states it plainly in Appendix A: “While entropy can be readily calculated for data with deterministic distribution functions, estimating entropy for user-chosen passwords is challenging. For this reason, a different and somewhat more straightforward approach based primarily on password length is presented herein.” The standard looked at the problem and retreated to counting characters. A meter in a web page is in no better position.
The reason is that length × log₂(alphabet) is the entropy of a process, not of a
string. It is correct only if each character really was drawn independently and uniformly from
that alphabet. Given the eleven characters Tr0ub4dor&3, the formula cannot
tell whether they came from a random generator (72.3 bits, and the figure is right) or from a
well-known cartoon about password strength (close to zero bits against anyone who has seen it,
and the figure is nonsense). The string is identical. Only the history differs, and the history
is the part that was never typed into the box.
There is a measurable instance of this on QuikUtil itself. Our own password generator draws from a pool of exactly 87 characters and reports 103 bits for its default 16-character output. Paste that same password in here and this page reports 105.1 bits, because it sees that a symbol is present and credits the full 33-character punctuation class rather than the 25 symbols the generator actually used. Two bits apart, on the same string, on the same site. The generator is the one that knows how the password was made, so its figure is the one to trust.
Comparing a proposed password against a list of known-bad ones is the mitigation NIST actually asks for, and it is mandatory: “When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.” The standard names what belongs on it, including “Passwords obtained from previous breach corpuses”, “Dictionary words” and “Context-specific words, such as the name of the service, the username, and derivatives thereof”.
The list behind the bar above contains twenty strings. It catches
password, which scores Very weak at 9/100. Add a single trailing space and
password scores Fair, 51/100, because the comparison is an
exact match on the whole input and the space is additionally credited as a whole punctuation
class. NIST anticipates precisely this behaviour and requires verifiers to push back on it:
“Verifiers SHALL offer guidance to the subscriber to help the subscriber
choose a strong password. This is particularly important following the rejection of a password
on the blocklist as it discourages trivial modifications of listed weak passwords.”
In fairness to short blocklists, NIST does not ask for an enormous one, and explains why: “Excessively large blocklists are of little incremental security benefit because the blocklist is used to defend against online attacks, which are already limited by the throttling requirements”, where the throttling requirement is that a verifier “SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator.” A list sized against 100 guesses is a reasonable list. Twenty is not that list, and a list cannot help at all against an attacker who has stolen the password file and is guessing offline, where there is no limit to exceed.
Whether your password is in a breach. This is the single most useful fact about a password and it is unavailable here by construction. Checking it means transmitting something derived from your password to a service that holds breach data. Nothing typed into this page leaves your device, so the question cannot be asked. The trade is deliberate, and you should know which side of it you are on.
How the site you use stores it. A 100/100 password is worth nothing if the other end keeps it badly, and that is where the standard puts its real weight: “Verifiers SHALL store passwords in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using a suitable password hashing scheme”, with a cost factor that “SHOULD be as high as practical” and a salt “at least 32 bits in length”. You cannot audit that from the login form, and no meter can see it.
Whether anyone is rate-limiting the guesses. A 60-bit password behind a 100-attempt lockout is fine. The same password in a leaked database is not. Which world you are in is a property of the service, not of the string.
Your actual length, if you use characters outside the basic alphabet. The Length row counts JavaScript string units, not characters as the standard defines them. Eight key emoji are reported as a length of 16. SP 800-63B-4 is explicit that “Each Unicode code point SHALL be counted as a single character when evaluating password length”, which would make it eight. Emoji in passwords are rare and portability between devices is a genuine problem with them, but if you use them, the number above is not the number the standard means.
Anything about the attacks that do not involve guessing. Appendix A again: “Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy and complex passwords as they are on simple ones.” No score on this page moves in response to any of them.
Part of the QuikUtil tools collection. Nothing you type here leaves your device.
crypto.subtle is
restricted to secure contexts and that the specification “provides no lower-bound on the
information theoretic entropy present in cryptographically strong random values”, which
is the limit on what any browser-side generator can promise.
w3c.github.io/webcryptoWhere a figure above is an estimate produced by this page rather than a published number, it is labelled as an estimate. Nothing on this page is legal or compliance advice; SP 800-63B-4 binds US federal agencies and their service providers, and is widely adopted elsewhere by choice rather than obligation.
For a password that is the only factor, NIST SP 800-63B-4 (July 2025) requires a minimum of 15 characters: “Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” Eight characters is permitted only for passwords “only used as part of multi-factor authentication processes”. The same section says verifiers “SHOULD permit a maximum password length of at least 64 characters”.
No. The check runs in your browser, in JavaScript you can read with View Source. Nothing is uploaded, stored or logged, and you can disconnect from the network and watch it keep working. That design is also the reason it cannot tell you whether your password has appeared in a breach: answering that requires asking someone else.
Length multiplied by the base-2 logarithm of a character-set size, where the set size is built by adding 26 for any lower-case letter, 26 for any upper-case letter, 10 for any digit and 33 for any other character. Sixteen lower-case letters gives 16 × log₂26 = 75.2 bits. It is the figure you would get if every character had been drawn at random from that set, which is true of a generated password and false of one you invented.
Not in the way password rules assume, and requiring it is now forbidden. SP 800-63B-4 section 3.1.1.2: “Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.” Appendix A of the same document gives the reason: a user who would have picked “password” is “relatively likely to choose ‘Password1’ if required to include an uppercase letter and a number or ‘Password1!’ if a symbol is also required”.
No, and until 6 October 2026 it did. Up to 48 of the 100 points used to come from the number of character classes present, which is why an 11-character password using all four classes was labelled Strong at an estimated 72.3 bits while 25 random lower-case letters, at an estimated 117.5 bits, was only Good. The grade now comes from the entropy itself, so the same two land Fair at 70.9 bits and Strong at 117.5. Character classes are still reported, because describing a password is not imposing a rule on it, but they earn nothing. Measured 6 October 2026.
Not on a schedule. SP 800-63B-4 section 3.1.1.2: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.” Rotation on a calendar is out; rotation on evidence is mandatory.
Yes, when the words are chosen by dice or software rather than by you. EFF’s long wordlist holds 7,776 words, each contributing about 12.9 bits, and EFF recommends “a six-word passphrase with this list, for a strength of 77 bits of entropy”. Four words is about 52 bits. The word random carries the whole claim: words you picked because they mean something to you are worth far less than the arithmetic suggests.
No, and no amount of entropy changes that. Attackers replay known email and password pairs against other sites first. SP 800-63B-4 Appendix A makes the wider version of the point: “Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy and complex passwords as they are on simple ones.” A unique password per site and a second factor both do more than another symbol.