Under the hood · 5 min read

Character sets, look-alikes and Unicode in passwords

The character sets behind password strength figures, the real cost of leaving out confusable characters, and why accented letters can break a login.

Every password strength figure starts with a count: how many different characters could appear in each position. Change that count and the bits per character change with it. This guide covers where the usual counts come from, what it costs to drop characters that are easy to misread, and what changes when passwords go beyond ASCII.

The 94 printable ASCII characters

ASCII, standardized for networks in RFC 20, has 128 codes. The first 32 and the last one are control codes such as tab and newline. Code 32 is the space, which RFC 20 lists as “Normally Non-Printing.” That leaves codes 33 to 126: 94 visible characters, the set behind most “all characters” password settings.

They split into four classes:

The 32 symbols, in ASCII order:

!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

26 + 26 + 10 + 32 = 94. Bits per character for common subsets:

Adding the space would make 95. NIST SP 800-63B-4 says services “SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords,” which is what makes passphrases with spaces possible.

Look-alike characters

Some characters are hard to tell apart in common fonts, especially on paper or a phone screen:

• I (capital i), l (lowercase L), 1 (one) and | (vertical bar)
• O (capital o), 0 (zero) and o (lowercase o)

When a password will be read by a person and typed by hand, for example a Wi-Fi password on a card or a temporary password read over the phone, these cause errors. Many generators, including this site’s, have an option to leave them out. The option removes exactly those seven characters.

Worked example: what excluding look-alikes costs

Removing 7 characters from 94 leaves 87.

• Per character: log2(87) = 6.443 bits instead of 6.555, a cost of 0.112 bits per character.
• For a 20-character password: 20 × 6.443 = 128.86 bits instead of 131.09, a cost of 2.23 bits.
• To make up the difference: 131.09 / 6.443 = 20.35, so 21 characters from the reduced set (135.30 bits) carry more than 20 from the full set.

For letters and digits only, removing the six look-alikes in that set (I l 1 O 0 o) leaves 56. Twelve characters then give 12 × log2(56) = 69.69 bits instead of 71.45. Adding a single character covers the loss.

So the look-alike option costs about one extra character. If it prevents a typing error that leads someone to pick a simpler password, it is a good trade.

Symbols: strength versus friction

Symbols add the most to the per-character count, from 5.954 bits (62) to 6.555 (94). They also cause the most trouble:

• Some sites reject certain symbols, often quotes, angle brackets or the backslash. NIST’s Appendix A says such rejections are usually unnecessary: “an unhashed password would not be sent intact to a database.”
• Phone keyboards hide most symbols behind extra key presses.
• Some symbols are hard to describe out loud.

Length can buy back what dropping symbols costs: at 20 characters, letters and digits give 119.08 bits against 131.09 for all 94, and two more characters (22 × 5.954 = 130.99) nearly close the gap. Length beats complexity works through this in more detail. NIST also says verifiers “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types).”

Beyond ASCII: Unicode

Passwords can contain accented letters, other scripts and emoji. NIST says verifiers “SHOULD accept Unicode [ISO/ISC 10646] characters in passwords” and that “Each Unicode code point SHALL be counted as a single character when evaluating password length.”

The difficulty is that Unicode often has more than one way to write what looks like the same character. The letter é can be stored as:

• one code point, U+00E9 (LATIN SMALL LETTER E WITH ACUTE), or
• two code points, U+0065 (e) followed by U+0301 (COMBINING ACUTE ACCENT).

They look identical. Different keyboards, operating systems and input methods can produce either. To a hash function they are different byte sequences: in UTF-8, “café” is 5 bytes in the first form and 6 in the second, and the two hash to completely different values. A password set on one device might fail to match when typed on another.

Normalization

Unicode Standard Annex #15 defines normalization forms that turn equivalent sequences into one standard sequence. NIST specifies which one to use:

“If Unicode characters are accepted in passwords, the verifier SHOULD apply the normalization process for stabilized strings using the Normalization Form Canonical Composition (NFC) normalization defined in Sec. 12.1 of Unicode Normalization Forms [UAX15]. This process is applied before hashing the byte string that represents the password.”

Under NFC, both forms of é become the single code point U+00E9. Another example: the ANGSTROM SIGN, U+212B, becomes U+00C5, the ordinary letter Å.

NFC deliberately does not merge characters that are merely similar. Fullwidth Ａ (U+FF21) stays distinct from A, and the ligature fi (U+FB01) stays one character rather than becoming f + i. Those are compatibility equivalents, handled by the NFKC form, which NIST does not call for.

NIST also adds a caution: people using Unicode passwords “SHOULD be advised that some endpoints may represent some characters differently, which would affect their ability to authenticate successfully.”

Unicode and generators

A generator could draw from thousands of Unicode characters and claim many bits per character. In practice that trades a little strength for a lot of risk: characters that cannot be typed on every device, that render as empty boxes, or that normalize differently. This site’s password generator sticks to printable ASCII and gets its strength from length, which works everywhere. Unicode also interacts with length limits measured in bytes, covered in password length limits.

General explanation, not advice for a particular situation. Updated 2026-10-31.