Avoiding ambiguous characters is just one part of user-friendly password generation. Using a password manager like Bitwarden eliminates the need to manually type passwords altogether, making character ambiguity a non-issue.
Every password generator faces a quiet design decision that most users never notice until something goes wrong: whether to include characters that look nearly identical to one another. The lowercase letter "l", the uppercase letter "I", and the digit "1" can be visually indistinguishable depending on the font. The digit "0" and the uppercase letter "O" suffer from the same problem, as do less obvious pairs like the digit "5" and the letter "S", or "8" and "B". These are collectively known as ambiguous characters, and the choice to exclude them is one of the most practical usability features a strong password generator can offer.
A character is considered ambiguous when its rendered glyph closely resembles that of another character in the same character set. The problem is fundamentally about visual perception rather than about the underlying data. To a computer, "1" (Unicode U+0031) and "l" (U+006C) are entirely different values with different binary representations. There is no technical confusion at the machine level. The confusion is entirely human and entirely dependent on typography.
The most commonly flagged ambiguous characters include the following:
Whether two characters are confusable depends heavily on the typeface being used. In a font with serifs, the uppercase "I" gains distinctive top and bottom strokes that separate it clearly from a plain vertical "l" or "1". In a monospaced coding font, the digit "0" is frequently drawn with a slash or a dot in the center precisely to disambiguate it from the letter "O". But a password is not displayed in a controlled environment. It might appear in a sans-serif system font on a phone, a serif font in a printed document, or a sticky note written by hand, where the ambiguity becomes even worse.
Passwords are a uniquely hostile context for ambiguous characters because of how they are used. A password is, by design, a random or pseudo-random string with no semantic meaning. When you read ordinary text and encounter an ambiguous glyph, your brain resolves it using context. If you see "He11o" you instantly know it should be "Hello" because the word makes sense and the digits do not. There is no such safety net in a password. The string "Il1O0o" carries no internal logic that would let a reader self-correct a misread character.
This becomes a real problem in several common scenarios:
Each of these failures produces the same outcome: a lockout. The user is certain they typed the correct password, the system rejects it, and after several attempts the account may be temporarily locked or the credential discarded entirely. This erodes trust in the password generator and, paradoxically, can push users toward weaker, more memorable passwords that they choose themselves.
Removing ambiguous characters from the available pool does reduce the total number of possible characters, which in turn slightly reduces the entropy contributed by each character position. Entropy is the mathematical measure of password strength, expressed in bits, and it is calculated from the size of the character set and the length of the password. Shrinking the character set lowers the per-character entropy.
Consider a full character set. A typical alphanumeric pool with mixed case and digits contains 62 characters: 26 lowercase, 26 uppercase, and 10 digits. Each character of a random password drawn from this set contributes roughly 5.95 bits of entropy, since the base-2 logarithm of 62 is about 5.95. If you exclude the most common ambiguous characters, you might remove perhaps eight characters, leaving a pool of 54. The per-character entropy drops to about 5.75 bits, the base-2 logarithm of 54.
The crucial insight is that this loss is small and easily recovered. The difference between 5.95 and 5.75 bits per character is roughly 0.2 bits. Over a sixteen-character password, that amounts to about 3.2 bits of total entropy lost. You can compensate completely by adding a single additional character to the password length, since each new position adds another 5.75 bits. In other words, a seventeen-character password from the reduced set is stronger than a sixteen-character password from the full set. The usability benefit is enormous and the security cost is trivial when length is even marginally increased.
A well-designed password generator should treat ambiguous-character exclusion as an optional setting rather than a forced behavior, because the right choice depends on how the password will be used. For a password destined to live only inside a password manager and be filled automatically by software, the visual ambiguity is irrelevant, and the full character set should be used to maximize entropy. For a password that a human will read, type, dictate, or write down, exclusion is strongly preferable.
Several principles guide a thoughtful implementation:
Ultimately, the question of whether to include 1, l, I, 0, and O is a microcosm of good security design as a whole. The strongest password is worthless if a human cannot reliably enter it, and the most usable system is dangerous if it sacrifices meaningful security. By understanding that ambiguous-character exclusion costs almost nothing in entropy while preventing a genuine and common class of human error, designers can offer a feature that respects both the mathematics of cryptographic strength and the realities of how people actually handle their credentials.
Store passwords with NordPass.