Most password advice is a list of rules — one capital, one number, one symbol — and the rules are a poor proxy for the thing that actually matters. Toolsyy’s Password Generator shows you the thing itself: a number of bits. This is what that number means, how it is calculated, and the two places where the honest answer is more interesting than the marketing one.
Strength is entropy, and entropy is arithmetic
The strength figure under the password is not a score someone invented. It
is length × log2(alphabet size), rounded down — the number of
bits an attacker has to search through if they know exactly how the
password was made and have to try every possibility.
With every character type selected the alphabet is 74 characters, which works out at about 6.209 bits each:
- 6 characters → 37 bits (Weak)
- 12 characters → 74 bits (Fair)
- 16 characters → 99 bits (Strong)
- 17 characters → 105 bits (Very strong)
- 20 characters → 124 bits
- 64 characters → 397 bits
There is a quirk worth knowing in that list. The label flips to Very strong at 100 bits, and the default 16 characters comes to 99 — one bit short. Nudging the slider a single notch to 17 crosses the line. If you have been wondering why a sixteen-character random password refuses to earn the top label, that is the entire reason, and it is a threshold rather than a judgement about your password.
The alphabet is 74 characters, not 94
Printable ASCII would give 94 characters to choose from. This generator deliberately uses fewer, leaving out the ones people misread:
- Capital I and O — confusable with lowercase l and zero
- Lowercase l — confusable with capital I and the digit 1
- The digits 0 and 1
That leaves 24 uppercase, 24 lowercase, 8 digits
(23456789) and 18 symbols
(!@#$%^&*()-_=+[]{}).
This is a real trade and it is worth being straight about the cost. A 94-character alphabet carries 6.555 bits per character against 6.209 here, so at sixteen characters you give up 5 bits — 104 against 99. That sounds worse than it is: one extra character more than buys it back, since 17 characters of this alphabet reaches 105 bits. You trade a character of length for a password you can read off a screen without squinting at whether that is an l or a 1, and the arithmetic comes out ahead.
Modulo bias, and an honest account of how much it matters
Here is the bug that lives in a great many password generators. You have a random 32-bit number and an alphabet of 74. The obvious way to pick a character is the remainder:
character = alphabet[randomNumber % 74] // subtly wrongThe problem is that 232 does not divide evenly by 74. It leaves a remainder of 44. So as the random number sweeps its whole range, the first 44 characters of the alphabet come up one extra time each, and the remaining 30 do not. Those 44 characters are slightly more likely than the rest, and the distribution is no longer flat.
Now the honest part, because this is usually oversold. At 32 bits that skew is about one part in 58 million. No realistic attack exploits it, and a password built with the naive version is not meaningfully weaker.
The generator corrects it regardless, by rejection sampling — computing the largest exact multiple of 74 that fits inside 232, throwing away any value at or above it, and drawing again:
limit = floor(2^32 / 74) * 74
draw until value < limit
character = alphabet[value % 74]Two reasons that is the right call even though the bias is tiny. The correction is effectively free — a redraw happens about once in a hundred million draws, so in practice the loop never runs twice. And the identical mistake made against a smaller random source is not tiny at all: the same line of code fed by an 8-bit value skews an alphabet of 74 severely enough to matter. Getting it right at 32 bits is how you avoid getting it catastrophically wrong somewhere else.
One incidental detail: when only digits are selected the alphabet is 8 characters, and 8 divides 232 exactly. That draw can never be rejected, because there is no uneven tail to fall into. Powers of two are the one case where the naive version was always fine.
Guaranteeing one of each type costs 0.28 of a bit
Sites that demand a digit and a symbol will reject a random password that happens to contain neither, so the generator picks one character from every selected set first, fills the rest from the combined pool, then shuffles the result with Fisher-Yates so the guaranteed characters do not sit in predictable positions.
That guarantee has a price that most generators never mention. Ruling out every password that lacks a symbol also removes those passwords from the space an attacker has to search, so the true entropy is a little below the displayed figure. At sixteen characters the real number is 99.07 bits against a nominal 99.35 — a cost of about 0.28 of a bit. At twenty characters it falls to 0.16.
A quarter of one bit, in exchange for never having a password bounced by a signup form, is a trade worth making. It is listed here because a strength figure you cannot interrogate is not much better than a coloured bar.
What this means in practice
Length beats complexity, and it is not close. Each extra character multiplies the search space by 74. Adding a symbol type to a short password merely widens the alphabet a little. A 20-character password of nothing but letters is far stronger than an 8-character one bristling with punctuation — and considerably easier to type on a phone.
Uniqueness matters more than either. The overwhelmingly common way an account is lost is not a cracked password; it is a password reused on a site that got breached. A 99-bit password protects nothing if the same string is sitting in someone else’s leaked database. Which is why the advice ends where it always ends: generate a different one everywhere, and keep them in a password manager, because the only workable answer to remembering dozens of unique passwords is not to.
Nothing generated here is transmitted, logged or stored. The password exists in the page and nowhere else, so copy it before you close the tab — once it is gone it is not recoverable, which is the intended behaviour rather than an oversight.
FAQ
Why does a 16-character password show 99 bits and not 100?
Entropy is the length multiplied by the base-2 logarithm of the alphabet size, rounded down. The alphabet here is 74 characters, which is about 6.209 bits each, so sixteen characters come to 99 bits. The label changes to Very strong at 100 bits, so a 16-character password lands one bit short of it. Moving the slider to 17 gives 105 bits and crosses the line.
Why are I, l, O, 0 and 1 missing from my password?
They are the characters people misread or mistype when a password has to be copied off a screen, read down a phone line or typed on a keyboard that is not theirs. Leaving out capital I and O, lowercase l, and the digits 0 and 1 shrinks the alphabet from 94 possible characters to 74, which costs about 5 bits at sixteen characters. Adding a single character more than wins that back.
What is modulo bias, and does it matter here?
Folding a 32-bit random number into an alphabet with the remainder operator makes the earliest characters slightly more likely, because the range does not divide evenly by the alphabet size. At 32 bits the skew is roughly one part in 58 million, which is negligible in practice. The generator removes it anyway by discarding and redrawing the few values that fall in the uneven tail, because the correction costs almost nothing and the same mistake on a smaller random source is genuinely exploitable.
Does guaranteeing one character of each type make the password weaker?
Very slightly, and the trade is worth it. Requiring at least one character from every selected set rules out the passwords that happen to contain none, which shrinks the pool of possible results. At sixteen characters that costs about 0.28 of a bit out of 99. In exchange, the password is never rejected by a site that insists on a digit or a symbol.
Is a password generated here safe to use on a real account?
Yes. It is drawn from your operating system cryptographic random source by way of the browser, the same class of generator used for encryption keys, rather than from an ordinary predictable one. It is never transmitted, never written to storage and never recoverable afterwards, so closing the tab without copying it means it is gone for good.
Related guides
- UUID v4 vs v7: which should you use? — the same cryptographically secure source, used for identifiers instead of secrets.
- How to verify a file checksum — hashing explained, and why a stored password hash is not the same thing as a checksum.
- Base64 encoding, explained — why Base64 is encoding rather than encryption, and never protects a secret.
Try it now: Free Password Generator