We are at a fairly early stage in our application development and have run into a usability issue related to typing an activation code sent via SMS into a browser URL.

Here's the basic scenario:

  1. You can sign up with email or phone
    • if you sign up with email, you get an email with a link to activate;
    • if you sign up with phone, you get an SMS with a link to activate.
  2. You click the link to activate, then set a password.

We had someone attempt this with a "dumb phone" (standard clamshell with no web browsing ability). This person did not have an email she felt comfortable sharing or using for our service. She proceeded to type the activation url into a browser on a desktop computer.

However, it turned out the activation code had enough confusing numbers and letters in it to require multiple attempts before getting it right (e.g., ones and zeros were hard to distinguish, "l" or "1" or "O" or "0").

Sample activation code: AX6elp90grPo

Initial Fix

We plan to address the immediate issue by "guessing" which letters and numbers seem easy to confuse with each other and eliminating them, or always using one (e.g., anything that looks like a "1" is always a "1").


I was wondering if there is already a standard recommendation or practice for situations like this (specifically, which letters or numbers should be eliminated)?

I'm also open to any other relevant suggestion, including how better to handle activation information over SMS.

  • 1
    Never came across a standard recommendation but would be interested to see your outcome later.
    – tamimat
    Commented May 8, 2012 at 14:45
  • 1
    Is the length of the activation code flexible? Google's 2-step authentication uses 6 digits and is (I hope) secure. 6 digits would remove the "1/l" issues and still be challenging enough to brute force. Commented May 8, 2012 at 14:55
  • 3
    Could you find a solution that used a coupling between the entered phone number/email address and a phrase, where the user identifier coupled with the phrase is the activation code? E.g Activation code: 00468465599BananasAreBlueIndeed Where the prefix number is the phone number the user entered and the suffix phrase is a phrase provided by you. Just and idea, don't know how it would fit though. Commented May 8, 2012 at 15:01
  • 2
    There should be some overlap on guidelines for issuing passwords where you'll get the same problems with ambiguous characters.
    – PhillipW
    Commented May 8, 2012 at 15:04
  • 9
    Your sample activation code is also way too long. Over on English.SE someone suggested the character set A B C D E F G H I J L M N P Q R S T U W X Y Z 3 4. With this all-uppercase entropy pool of 25 elements, a code of only 3 characters only has a 0.0064% chance of being guessed ((1/25)^3). You don't need to annoy your user by forcing them to type in 12 characters. Software product activation keys are long expressly to prevent brute-forcing, which probably isn't a problem for you (i.e., expire the account after 3 failed attempts).
    – msanford
    Commented May 8, 2012 at 18:06

7 Answers 7


Since you really seem to care for your users and think through your interface, I have one suggestion: Users should never have to manually type arbitrary codes!

Instead, just generate a code from a freely available English wordlist:

Your activation code is "Large Sinister"

Of course, interpunctuation, capitalization and spacing should not matter.

Edit: http://wcodes.org/ , as pointed out by other answers, is probably a good library to use.

  • 1
    The plain text activation code suggested above work perfectly in URLs, too. Just use a hyphen instead of a space.
    – Ben
    Commented May 8, 2012 at 17:44
  • 2
    I'll mention it to the team. Commented May 8, 2012 at 17:45
  • 3
    Yes, do that! We humans should not have to type long, arbitrary strings. :-)
    – Ben
    Commented May 8, 2012 at 17:49
  • 4
    On the other hand, this is more difficult for non-native speakers using your system. I can imagine my mom, who's able to use computer products in English, but is quite unable to spell anything. 6-char code is certainly easier for her than two English words, because she really has to treat the words as seperate symbols, instead of something natural.
    – yo'
    Commented Feb 18, 2014 at 15:43
  • 2
    @yo' If your mother can type arbitrary strings, she can type words just as easily. If she doesn't understand them, that makes them exactly the same thing as arbitrary strings!
    – Dan
    Commented May 26, 2017 at 20:08

Yes there are examples of how to solve your issue. pwgen has a list of ambiguous characters: B8G6I1l0OQDS5Z2 (it's in this file if you can read C code).

Another code-snippet is here, in PHP this time.

The former approach is using a "blacklist" approach, the latter instead a "whitelist" one.

  • I really appreciate the link to Tyler Hall's blog and its link to the source in GitHub. Commented May 8, 2012 at 15:19
  • I'd also add "UV" (which are easy to confuse when handwritten) and "9" (which can sometimes be confused for a lower-case g) Commented May 8, 2012 at 20:13

In general, assigned passwords should avoid ambiguous characters. An example is Microsoft activation codes; they do not use the letter O because some people might type a zero (0). Similarly, you should trim your allowed characters to remove any ambiguous or confusing ones from the set of possibilities. For example, this is the character set I use in generated passwords:

abcdefgh  k mnop rst  wx zABCDEFGH JKLMN PQR T  WXY 34 6 89

Any time a user called in because they failed to differentiate a character properly, it got removed from the list. This is why 2, 5, S, and Z got removed... I didn't think they were ambiguous, but they were after the user wrote them down.

I would like to add... if I recreated this password generator today, it would use the xkcd method (also used by AOL) of random short words.

  • 2
    +1 for responding to user confusion and the XKCD method. See my answer for more specifics on Microsoft's activation codes. Commented May 8, 2012 at 15:46
  • 1
    You've still got some ambiguities there. In some typefaces, it's difficult to distinguish rn from m.
    – TRiG
    Commented May 22, 2012 at 12:54
  • Good catch, though it had never come up yet in our case. It does help that we display our passwords in a fixed font for clarity, so the rn = m ambiguity has never hit us. But I have certainly seen that happen in other situations. Commented May 22, 2012 at 13:16

Base 32 encoding is a standard defined with this purpose. There are several variants, but all of them try to avoid ambiguous characters. This is the rationale from the article linked:

Base32 is a notation for encoding arbitrary byte data using a restricted set of symbols which can be conveniently used by humans and processed by old computer systems which only recognize restricted character sets.

  • 1
    Nice link, and it's fascinating too. The wikipedia article comes very close to explaining the background and rationale for a character set that is easy for human transcription. Commented May 8, 2012 at 16:51
  • 1
    This was the answer I was going to add when I saw this question. :) Commented Feb 18, 2014 at 16:39
  • -1 (down vote) Base 32 is for recording data in 5 bits, mapped to symbols. It's not inherently a low ambiguity symbol system. One of the example symbol sets in the Wikipedia entry is A-V and 0-9 and that symbol set contains ambiguity.
    – H2ONaCl
    Commented Nov 24, 2022 at 18:13

Microsoft has has to deal with user-legible activation codes for a long time. I suspect they have put some science into their decisions. I had a pile of activation codes from work to analyze. Here's a faked example code:


Firstly, all letters are UPPERCASE. This move alone should eliminate quite a bit of confusion. (I realize that removes entropy - if you had to, you could make that up by increasing the length slightly. What I'd actually recommend is presenting uppercase letters, but accepting either case for input.)

Looking across 31 codes with 25 characters each (775 characters total), the characters they did not use were:


0 1 5

Lastly, note that they break up their codes into chunks. I won't venture to guess how long a code would be before breaking them up would be useful, but you might consider this for experimentation.

  • 2
    If you break the code sent into chunks please make sure that the form that takes it also does so in the same chunked format. Having a 16 digit code broken into 4 sets of 4 digits doesn't help much when you have to type all 16 into a single box and can't manually input delimiters. Commented May 8, 2012 at 17:46
  • @DanNeely: The way the enter-box works for activating MS products actually works quite nicely.
    – André
    Commented Sep 25, 2012 at 8:00

What you seek is an efficient Human-Computer code. What I recommend is to encode the entire data with literal(meaningful) words, nouns in particular.

I have been developing a software to do just that - and most efficiently. I call it WCode.
Technically its just Base-1024 Encoding - wherein you use words instead of symbols.

Here are the links:
Presentation: https://docs.google.com/presentation/d/1sYiXCWIYAWpKAahrGFZ2p5zJX8uMxPccu-oaGOajrGA/edit
Documentation: https://docs.google.com/folder/d/0B0pxLafSqCjKOWhYSFFGOHd1a2c/edit
Project: https://github.com/San13/WCode (Please wait while I get around uploading...)

  • Can you summarise the idea here. No need to go into great detail, just enough to enable us to decide whether it's worth clicking on your links.
    – ChrisF
    Commented Oct 1, 2012 at 21:54
  • Just like in Base-64, 6 bits -> look-up table of 64 Symbols like a A; In the encoding I propose, 10 bits -> look-up table of 1024 Words like Apple Mango Commented Oct 2, 2012 at 4:27
  • @ChrisF Please see: wcodes.org the project is live on crowdfunding site:indiegogo.com @ igg.me/at/wcode/x/2245741 Commented Apr 17, 2013 at 16:37

One more vote (if I'd have reputation) for making the string itself easier to remember, like WCode or Ben's answer with "Large Sinister". On the international and technical side of things, the character set used should be http://en.wikipedia.org/wiki/GSM_03.38

  • -1 (down vote) There is ambiguity in the visual representations in that GSM character set.
    – H2ONaCl
    Commented Nov 24, 2022 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.