Password strength checker
Generated in your browser · never sent, never stored
This measures one thing: how many guesses an attacker would need if the password really were random. It reads the length and which character classes appear, and reports the entropy that combination could carry at best. Twelve characters of mixed case and digits is about 71 bits; eight of the same is about 48.
How to check a password
Be clear about the limitation, because most strength meters are not. This is an upper bound, not a score. "Password1!" contains four character classes across ten characters and scores as though it were random, when in reality it appears near the top of every cracking dictionary and falls in under a second. No meter that looks only at the characters can tell the difference. The number is meaningful for a password you generated randomly and misleading for one you invented — which is the strongest argument for not inventing them.
That same arithmetic is what answers "is twelve characters enough?", and it is worth using it that way. Because the calculation depends only on length and character classes, typing twelve characters that follow a rule tells you what the rule is worth: twelve of plain lowercase is about 56 bits, twelve with capitals and digits about 71, eight with capitals and digits about 48. Two policies that sound similar can be a factor of a million apart.
The composition rules themselves buy less than they cost. Allowing symbols grows the pool from 62 characters to about 95, which is roughly 0.6 extra bits per character; two more characters of length usually beat it. That is why current NIST guidance is to raise the minimum length, drop the mandatory capital and symbol, and check candidates against a list of known-breached passwords instead — the last of which is the part a character-counting meter can never do.
What people use it for
- Judging a password policy by typing a string that follows it
- Working out what a twelve-character minimum is worth in bits
- Comparing two policies that sound alike and are not
- Checking a password before it goes into a password manager
- Seeing what four more characters are actually worth
- Settling an argument about whether symbols matter
Questions
No. There is no network request on this page at all. The calculation is a few lines of arithmetic running locally.
Because the calculation assumes randomness. A dictionary word with a capital and a digit fits the pattern attackers try first, and no character-counting meter can see that.
Under 40 is weak, 60 is a sensible floor for an account that matters, and above 80 puts an offline attack out of practical reach.
log2 of the number of equally likely passwords the length and character set allow. 60 bits is roughly a billion billion candidates.
It depends what is in them. Twelve of plain lowercase is about 56 bits; twelve with capitals and digits about 71. For anything protecting other credentials, aim higher.
It grows the pool from 62 to about 95, worth roughly 0.6 extra bits per character. Adding two characters of length usually buys more.
Type any string that obeys it. The figure depends on length and character classes only, so a sample tells you what the rule is worth without involving a real password.
The same formula, with words instead of characters: bits are log2(list size) per word. A five-word phrase from a 30,000-word list is about 74 bits.
It is the input to that estimate. Time also depends on the attacker’s hardware and on how the site hashed the password, which can vary by a factor of millions.
Ten billion a second, which is roughly one modern GPU against a fast hash. Sites that hash properly are far slower to attack; the pessimistic number is the safer one to plan around.
Current NIST guidance says no: set a longer minimum and check against a list of known-breached passwords instead.
No. That would require sending something to a service, and this page does not make requests. Your password manager or browser can do that check.