Understanding and avoiding visually ambiguous characters in IDs

Original Article ↗ Hacker News Discussion ↗

Designing IDs that humans can reliably read, write, and say out loud turns out to be surprisingly hard once you account for visually and phonetically ambiguous characters like 0/O and 1/l/I, handwriting styles, fonts, and case sensitivity. Commenters weigh trade-offs between dense encodings (hex, base32, base58), word-based or “speakable” IDs, and techniques such as normalizing ambiguous input, adding checksums, omitting vowels to avoid accidental obscenities, and using phonetic alphabets. Many argue that slightly longer, well-structured, and error-detecting IDs are worth the extra length to reduce user frustration, security risks, and transcription errors in everything from serial numbers to 2FA backups and geolocation systems.

Use of Words vs. Alphanumerics for IDs

  • Some argue that when IDs are encodings of integers/bytes, representing them as words can aid memorization and verbal transmission and allow richer error detection.
  • Others note big drawbacks: much lower encoding density (IDs become far longer), need to curate huge wordlists (avoid phonetic similarity, subwords, offensive terms, obscure words), and accent‑dependent ambiguity.
  • Examples of curated wordlists (PGP, s/key, BIP‑39) are cited; several commenters find them verbose or culturally biased.
  • what3words is discussed as a related system: criticized for phonetic confusion (misheard addresses), proprietary control, and legal threats; some see it as inappropriate for something that behaves like core infrastructure.

Character-Set Design and Normalization

  • Many favor reducing the alphabet by removing visually ambiguous characters (0/O, 1/l/I, rn/m, cl/d, etc.), sometimes also vowels to avoid accidental obscenities.
  • Others propose keeping a larger alphabet but normalizing lookalikes to a single internal value (e.g., map |Il1 to “1”) to retain capacity without user-visible ambiguity.
  • Various encodings are mentioned: Crockford Base32, z‑base‑32, Bitcoin Base58/Base32, custom “base24/base32” schemes, all trying to balance compactness, readability, and ambiguity handling.
  • Checksums and structured formats (IBAN, coupon codes, error‑detecting serials) are highlighted as crucial additional defenses.
  • Grouping characters (with spaces or hyphens) and avoiding long runs of the same symbol are seen as important usability improvements.

Fonts, Handwriting, and UI Choices

  • Many problems arise from specific fonts (e.g., some render l/I identically) and regional handwriting styles (1 vs 7, 1 vs A, 9 vs g, n vs u), leading to cross‑cultural misreadings.
  • Suggestions include: using hyperlegible or specialized fonts, slashed zeros and crossed sevens, or FE‑Schrift‑like approaches; others warn some fonts optimize for machine, not human, readability.
  • Interfaces that disable ambiguous keys (e.g., game consoles) and password managers that color‑code character classes are praised, though colorblind users sometimes find color‑heavy cues problematic.

Spoken Transmission and Phonetics

  • NATO phonetic alphabet is recommended for spelling, but many users and non‑English speakers don’t know it, and accents create confusable pairs (F/S, B/P, D/T, M/N, etc.).
  • Word‑based or “speakable” IDs must handle homophones and dialects; getting untrained users to reliably convey codes by voice remains described as largely unsolved.