What a bit of entropy actually buys

Published 2026-11-03 · Last reviewed 2026-11-06

Every password meter puts a bar on the screen and calls it strong or weak, and almost none of them tell you what the bar measured. That is the part worth knowing, because the number behind it is small arithmetic anybody can redo: how long the password is, how large the set of characters it was drawn from is, and how many guesses an attacker has to make to walk that set. Everything else - the colored bar, the label, the years-to-crack figure - is that one multiplication dressed up.

The second half of the question is where the randomness comes from, and that half cannot be shown in a screenshot: a password generated from a predictable source is worth nothing however long it is. On this site both halves are stated on the page that uses them, and this guide is the long version.

A bit is one coin flip the attacker has to call

One bit of entropy means the space of possible answers is twice the size it would be with one bit less. Sixteen characters drawn from an alphabet of 86 fill a space of 86 to the power of 16 possibilities, and the bit count is the exponent you would need on a base of two to write the same number: 16 x log2(86) = 102.8 bits. That is why the number grows with both factors at once - one more character multiplies the space by the whole alphabet, while a wider alphabet multiplies it by a little less each time, because a logarithm of a bigger base grows more slowly.

The bit count is not a probability and it is not a measurement of the password you typed; it is the size of the space the password was drawn from, written in the unit attack cost is naturally measured in. Two passwords with the same bit count are equally expensive to guess by brute force, which is exactly the claim the formula can support - no more.

Where the alphabet size comes from

The generator on this site draws from four character classes and counts them honestly: 26 lower case letters, 26 capitals, 10 digits and 24 punctuation marks it is willing to type, which is 86 characters. The punctuation is a chosen list rather than every printable character - no quotes and no backslash, so the result can be pasted into a terminal or a spreadsheet without escaping anything.

Removing the lookalikes changes the number, and the page shows both: dropping I, l, 1, O, 0 and o leaves 80 characters, so sixteen characters is 16 x log2(80) = 101.2 bits instead of 102.8. Those 1.7 bits are the price of not mistyping a password somebody reads off a screen, and it is a good trade at sixteen characters.

The strength meter uses a different set of numbers on purpose: 26 + 26 + 10 + 33 = 95, the conventional sizes every meter uses for all printable punctuation. The two figures differ because they answer different questions - what the generator draws from, and what a password not made here might have been drawn from - and both are printed rather than quietly reconciled.

A phrase is measured in words, not characters

A passphrase has the same formula with a different alphabet: each word is a draw from a bank of 324 concrete short words, so 6 words is 6 x log2(324) = 50.0 bits. That is about the same as twelve characters of the widest alphabet, and it is far easier to type from memory, which is the whole reason the mode exists. The rule that follows is worth repeating: add words, not punctuation, when you want more.

The honest half of this is the blind spot. A character-set formula handed a long phrase prepared by a human sees 28 characters and prints a fortress; an attacker who knows English splits it into words and searches the word combinations instead, which is a far smaller space. So the meter on this site puts the character formula and the word formula side by side when it can, and refuses to call a phrase strong on the strength of the character count alone.

Why the arithmetic happens in this tab

The random part comes from crypto.getRandomValues, the browser's own cryptographic source - the same generator the operating system uses for keys. Two details make it correct rather than merely random-looking. First, every draw is uniform: a 32-bit value taken modulo an alphabet size is biased whenever that size does not divide the space evenly, so the code rejects the top of the range and draws again. Second, there is no seed box anywhere on the page: a password that can be reproduced from a number is a password anyone who learns the number can reproduce.

Doing this in the tab is not a performance choice, it is the only arrangement that keeps the promise the page makes. Nothing typed or generated is sent anywhere, so there is no server that could log a password, no request in the history, no upload endpoint to misconfigure. The measuring box is a password field, which the framework refuses to write into the address bar - so a password pasted into the meter never ends up in a bookmark or a shared link. The cost of that arrangement is that the page cannot check a breach list (that needs a lookup) and cannot remember a batch across a reload (that needs storage), and it says so instead of pretending otherwise.

Where these numbers come from

• Every figure above is calculated, not copied in. The alphabets, the bit counts and the word bank all follow the same entropy calculation: it builds the alphabet a set of settings draws from, applies length x log2(alphabet) to a character password, adds up the three phrase terms for a passphrase, and counts the word bank the word figure divides by. The tool page and this guide use the same calculation.
• Every release automatically checks the identities directly: the printed bits equal length x log2(the alphabet the page promises), every character of every password belongs to that alphabet, the lookalikes are absent when they were excluded, and the exported TXT and CSV carry exactly one line per password at the length asked for.
• The formula is cited, not invented. Length times log2 of the alphabet is the standard keyspace estimate, and it is an upper bound here because the generator guarantees one character from each class the visitor keeps. The three attacker speeds the crack times divide by are stated assumptions printed beside the times, not measurements of any particular machine.

What this guide does not cover

It does not measure how strong your password is in practice: reuse, phishing and a site that stores hashes badly are the things that actually get people breached, and none of them is visible in a bit count. It also does not cover password managers, two-factor authentication or how a service should store a password - those belong to the service, not to the person choosing one. And it says nothing about generating keys: a password for a person and a key for a machine have different threat models, and a page like this one should not be used to mint an API secret.

Generate one in the Password Generator, or use the same cryptographic source for something that is not a password: a UUID Generator or a Hash Generator.

Explanations only - not security advice for any particular system. Read the full disclaimer.