What are some compelling reasons to disallow spaces in usernames?

Question

I'm a developer. Our UX guy is asking us to allow spaces in usernames. The caveat is that they should be allowed anywhere.

So entering the username 'JohnDoe' is the same as 'John Doe' is the same as 'J ohn D o e'.

The username would be stored as 'JohnDoe' and on login submission we'll strip out spaces so we can match to our stored user.

The dev team agrees that there's something about it we don't like, but we can't really think of a compelling argument against it besides "it's not a standard practice".

Are there things we should be aware of in doing this that maybe we're not thinking about?

Answer 1

There are a few reasons not to allow spaces in usernames...

...most of which can be resolved with proper implementation:

• They need to be tested with 3rd party software. Even if your software allows spaces in usernames, if you are using 3rd party software libraries to handle usernames they may disallow spaces so you will have to at minimum test compliance and in the worst case create adapters to handle spaces in usernames for non-compliant libraries.

• Browsers wrap whitespace. So if a user name is J a s o n, you may get some awkward wrapping of the username when it's rendered by a browser at the end of a line. This can be worked around by rendering spaces as non-breaking in HTML.

• It makes usernames more difficult to parse. Most notably, for applications which allow users to be mentioned (e.g. that reply from @tohster really sucked), then parsing the mention can be difficult when spaces are involved. This can also be worked around with careful implementation (for example, Facebook allows users to be mentioned by names, including spaces).

• Leading and trailing whitespaces need to be managed carefully. It can be difficult to distinguish between _Jason, Jason_ and Jason (replace the underlines with spaces) when a username is rendered in a browser....so that can cause problems with user spoofing or confusion. This again can be worked around by disallowing leading/trailing whitespace, or by using non-breaking spaces to ensure usernames aren't collapsed.

• Sequential whitespace can be difficult to discern. For example, it can be hard to tell apart Jason Bourne, Jason Bourne and Jason Bourne, particularly if other users are typing in the usernames (e.g. to send a message or to mention the user). This can be worked around by disallowing sequential whitespaces, or by just livng with it.

None of these are particular show-stopping issues, so it's just a question of whether you are willing to take the effort/cost required to handle whitespaces properly, and whether you can live with some of the visual differentiation issues with similar whitespaced usernames.

• Although that doesn't sound compelling, I can tell you that in real life this set of complications is usually enough to cause the majority of companies to disallow usernames with spaces.

Microsoft Windows is a notable example of large-scale software which has allowed spaces in usernames for years. That said, even Microsoft recommends against using spaces in Windows usernames, because of some of the above issues. From this MSDN document:

Logon names can contain all other special characters, including spaces, periods, dashes, and underscores. But it's generally not a good idea to use spaces in account names.

---

But in your case...

..your UX guy is asking you to allow spaces during input but strip them out for everything else. So the user may enter J ason Bourne but then see JasonBourne as a response once it's resolved by the server.

While trimming leading and trailing spaces is somewhat common for username inputs (because cut-and-paste operations sometimes insert an unwanted leading or trailing whitespace), allowing spaces inside the name is a poor idea if you're just going to strip them out.

Your UX designer may believe that this will reduce UX friction, but that is not actually true. Usernames typically don't contain spaces, so allowing users to type in an invalid input and silently removing the space is overly presumptuous for the UX. It's better to detect the interstitial space and inform the user (e.g. Usernames can't contain spaces) so they can check the username again.

• For example, if the login input silently accepts Jason [email protected], then browser autocompletes may remember that username and continue to autofill it incorrectly in the future. It's better to just reject the invalid name and inform the user.
• For example, if a new user attempts to sign up with the username Jason Bourne, he may be surprised and confused when he receives a message back saying that username is already taken because JasonBourne is an existing username...even though he entered a username with a space in it.

Answer 2

Allowing spaces in logical "natural language like" input scenarios should not only be allowed, but encouraged. The name is not JohnDoe but John Doe. And same as one comment says (although trying to oppose to this view, so you can see it goes either way), the name is Experts Exchange, not expertsexchange and certainly not Expert Sex Change. And this is why you should enable spaces in usernames: accuracy and limitation of random occurences. Which doesn't mean random spaces. It means natural language spaces.

Also, keep in mind that clearing randomness applies to everything. I mean, you can sanitize inputs as a secondary step, but you should make very clear that username, with or without spaces, should be used in only one way. Going back to our friend, if he signed as JohnDoe, then his username will be JohnDoe, not John Doe.

Another thing: you can sanitize and filter usernames with these conditions:

• spaces before username
• spaces after username
• repeated spaces

This way, you only allow 1 (one) space. You can also restrict usernames to 2 words, and even offer an username option to the user, like this:

Welcome John Doe, please select your username

• JohnDoe
• John Doe
• or enter username

Finally, there's the usual middle point for your case: you may have one username/login, then have a display name. This is a very common approach, and one you should contemplate if you decide not to use spaces (after all, username is not the same as display name ). Since our good friend is not JohnDoe, nor johndoe69 nor [email protected] , I'd advise to either use spaces in your username OR allow display names selected by the user. Obviously, allowing usernames with spaces is the easier way, but if you don't do this, then use display names

Answer 3

You shouldn't alter user input to be stored in a database. Sanitizing is common and encouraged (you'll see whitespace trimmed from the ends of a string, for example). Since you're storing the information without white space, you can never retrieve the original input, and a user may be confused if they ever see their username (in a password reset email or a account/profile page) displayed differently than they had originally specified and expect.

So while from a development standpoint there may not be as strong of an argument against it, it's counter-intuitive to user experience.

Answer 4

It sounds like a misunderstanding.

The UX guy has two requirements

1. Allow whitespace in user names.
2. On login whitespace should be ignored for convenience. If the user forgets the whitespace or puts one in, although he shouldn't, he'll still get logged in.

You concluded

• "We'll store the username without whitespace."
  But you shouldn't alter the user input before storing it. The user will put more effort into setting up the correct username, than entering it on login. Keep it as it is.
• "Every future system will need to support 'strip whitespace'."
  No. The backend uses the original username without modification. Whitespaces will only stripped in the frontend. You'll be able to drop that feature by altering only one frontend application.

Developer Notes

• You'll probably need to store - in addition to the original user name - a simplified username without whitespaces for searching in database. That's nothing special, for example in Germany we often store the original name and a simplified name because of umlauts: "André Müller" becomes "Andre Muller".
• When creating new users, you must check if the simplified name already exists. Don't allow "Jack Shepard" if there is already "JackShepard".

Answer 5

If you really want to make things easy on the developer then just give every user a number and refer to them as that. Of course that doesn't make things easier for the user so most developers are okay with allowing people to input a sting of letters that is easier for the user to remember.

Since this is strictly about the User Experience I wanted to list some reasons for and against solely from a UX perspective.

---

1. Limiting user input requires additional communication

Nothing is more frustrating than having a website tell you to keep coming up with different passwords as they try and communicate all the criteria that your password has to meet. There was a similar discussion about preventing certain characters in passwords and although passwords aren't exactly the same as usernames many of the points still apply.

2. Allowing spaces isn't the same as requiring spaces

Just because spaces and special characters are allowed doesn't mean people will use them. Chances are that if you don't prevent any input in the username at all most people will still choose something short and easy for them to remember and type.

3. Spaces allow users to be a little more anonymous

Not all users want to be easily recognizable and/or tagged. Users that want to be easily recognized will not use special characters or spaces in their name while other users should still have the option of "obfuscating their name". Just make sure that all the user input is preserved to avoid collisions. This means that adding 2 spaces between John and Doe is a different username than only adding 1 space between John and Doe.

---

There is one really good reason why allowing spaces in usernames provides a bad user experience.

1. Trolls and Phishing and ID Theft oh my!

If users in your application can communicate with each other and the username is their only identity for this conversation then allowing spaces is not a good user experience since it essentially makes it easier for a bad user to imitate a good one. This can be mitigated by showing reputation along side the username but too many people would equally trust John Doe (good guy) and John Doe (bad guy).

If, on the other hand, your application isn't social and the username / password is only used to authenticate a single user then I wouldn't place any limitations on their username or password.

Good luck in making your case!

Answer 6

Spaces? Sure.

From a user's perspective anyway. Your system may have problems with spaces or special characters, but users don't care about that stuff. They are more forgiving with passwords, but user names are something they want control over.

Variable? No.

Your UX guy is getting a little crazy with this idea. Spaces are fine, but only if the user asked for a space. If the user name is Fire Breather, don't allow variations of that sequence of characters like FireBreather. As you point out, once you allow that variation you have to allow all variations and your user authentication gets pretty messy.

The only parallel I can think of is Gmail's acceptance of a period anywhere in your address. That also seems a little silly and isn't used often.

If the concern is auto-correct/suggest/capitalize, just disable that feature for the input field. In most cases, it should be disabled anyway.

Sidebar: case

I do, hesitantly see value in allowing variation of case. I'm not fond of it, but some users forget that they used intercaps or all lowercase. If you treat each glyph as it's canonical alpha-numeric value during authentication, you can accept variation.

Answer 7

Names differing only in the number and location of spaces are not semantically the same names! What happens if Michelle Blanc and Michel LeBlanc both want to create an account on your system?

I'd be all for allowing Michelle Blanc to choose whether she wants to use a space or not, but it's not possible to then allow her to arbitrarily insert spaces anywhere she wants when logging in without denying Michel LeBlanc the possibility of using his name as his username.

Of course you may decide this is not a problem since a different Michelle Blanc also can't use her name any more...

Answer 8

Fails the principle of least astonishment: For years users have learned that not typing their usernames exactly at login will disallow login. Breaking that is surprising. This surprise may lead to reduced trust in any aspect of the software -- since "close enough" is good enough for usernames, I imagine it's also good enough for passwords and for the functionality of the application. Or is this the only use of "close enough" in the application so that yet another astonishment is waiting?

Answer 9

Provided all you're doing is strip spaces from user input coming the login form, I think this is a reasonable idea with no downsides.

There are no code changes needed besides the immediate translation that happens at the login form, that removes all spaces.

The user sees no difference in the UI, except that it used to be a hard error message when he used a space, now he gets logged in (if the rest of the form is correct).

That said, I don't expect it to be useful very often. It's really minor.

Answer 10

Ambiguity

Helena Beckett and Helen Abeckett are the same username. That's problematic.

Better solution

Collect a username without spaces, and a separate "Display name" with spaces. Added benefit: They can change their display name without messing anything else up.

Answer 11

I think that there is a major question that should be answered here:

Will the usernames that you mention also be used within natural language?

It sounds to me as if your UX guy is trying to simplify the interface by merging the username field with the real name field. If that is indeed the case, then you should consider this:

A person's name is what people call then in every day life, but it's hardly a unique identifier. Therefore for any username derived from real names you are going to get duplicates. Duplicates that people will deal with in various ways, such as adding their middle name, their birth year or even a plain old counter.

When an application has separate fields for the username and the real name, then the 69th user named John Smith will have to bear typing johnsmith69 when logging on (which should not be all that often, especially if you are using an SSO) and when sharing their account information, but they would still see "Hello John Smith" on the welcome page.

I expect that the same user would be very annoyed if they had to contend with seeing "John Smith 69" everywhere, whitespace or no whitespace.

In addition, there can be legitimate reasons for using a username that has little to do with their real name. E.g. legacy systems that only support usernames with 8 characters, systems that expect mail-like usernames or even just users that like to simplify their lives by using a limited number of usernames everywhere. If you tie the person's real name to their username is whatever form then you limit their choices.

In my opinion you should just do what most people are already doing:

1. Ask people for their real name and store it for use in a natural language context.

2. Generate a unique username based on their real name, fill-in the appropriate form field and then allow people to change it, making sure that it is still unique and that it is conservative enough for interaction with legacy systems.

Answer 12

I see no reason, UX or programming, by which it shouldn't be allowed. Because you said that the spaces would be removed before acting upon it, this is not much different than asking "Should I allow users to enter in parentheses or hyphens in phone numbers when asking a user their phone number?". The answer to that is, of course — as long as you're properly processing that input serverside.

Already in most login systems, a person whose username is christopher can enter in his username as ChrisTOpher, CHRISTOPHER, ChristophER. Many systems will also strip leading and trailing spaces, allowing ␣␣Christopher, or Christopher␣␣␣␣ (where ␣ is a space). There is no surprise to the user that if they type in any of the aforementioned names that they get logged in as if they had typed in christopher. Since no one else will have the internal username christopher, there aren't any surprises for other users.

Presumably, you're already server-side doing something analogous to

$username =~ lc($username);    # lowercase the username
$username =~ s/(^\s+|\s+$)//g; # strip trailing/leading spaces

Literally, the only thing you'd be changing would be making the second regex be s/\s//g, which actually makes it simpler.

The edge case of someone entering in an all-space username is a non-issue if you're properly validating, normalizing, sanitizing, and escaping the user input serverside (or just add a simple check for it, which you should be doing anyway — just because the form doesn't allow submission doesn't mean someone can't submit the form data anyways. Never ever trust user input). The only real concern would be if you're using e-mail addresses as the login (where spaces are semantically significant), but that's a different security concern entirely.

Answer 13

The reason it feels wrong is that allowing spaces creates the premise of redundancy, and redundancy is bad UX (no matter what the expert says). Your application probably already captured First Name and Last Name as individual fields, right? When the user put in "John" and "Doe" they imparted to you that their name was John Doe. To further go on and allow them to pick a user name of "John Doe" is, to them, a waste of time (and you can't pick it for them, because...) Finally, to say to them "pick a user name with spaces that is unique" and John is forced to use "John Doe 6" he feels quite clumsy and even alienated.

Better to just ignore the pretense of proper name formatting entirely, or like many sites do (which I think is an idea nearly everyone should adopt) just use the email address as the username.

Answer 14

Because the requirements around user names are not a UX concern, they are a technology/business/security concern.

Primarily, usernames function as unique identifiers that allow information to be tied to a single individual and allows that individual to be tracked and accurately interacted with by the application and its supporting systems. As such, the driving factor behind the input rules for a username should be meeting the needs of the systems in a secure and efficient manner.

If the UX resources are concerned about the experience that comes with a non-"human friendly" username, there are certainly routes to take that can improve that . . . aliases, display names, alternate logins (e.g. "Enter email address or username"), application/site designs that minimize username exposure/interaction, etc.

If you are really having a problem selling this point, I would suggest asking the UX resource to provide the evidence that he has (user testing results, user feedback, industry standards, competitors use of the practice, etc.) that shows that allowing spaces in a usernames provides an improved user experience, to the point that it trumps the requirements of the technology/business/security needs.

Answer 15

I am a Drupal developer and a module maintainer. Drupal's internal registration system defaults to allowing spaces, hence drawing a LOT of attention from spambots which have no spaces in their usernames. I wrote a module specifically to enforce spaces in usernames. Long story short, a username with spaces should be enforced in my humble opinion.

Answer 16

So, what if I were to create a username of just a bunch of spaces, like this:              ? From what I understand, this would be a valid username. However, once you trim the white spaces I no longer have a username, and probably just broke your page.

Answer 17

I see lots of users using client software which for unknown reasons insert a space at the end of input fields.

A user using such a client sometimes but not always could get into problems. They sign up with one client but later attempt to sign in with a different client, which does it differently. Then they'll be told their username is incorrect.

For me that is a compelling reason to strip trailing spaces. And while we are at it, striping leading spaces sounds sensible too.

There is a drawback if the field is not allowed to be empty though. If there is a specification saying the field must contain at least one character, then it is valid for the client to send a string consisting of just a space. But if the server then removes any trailing spaces, it may end up with an empty string anyway even if the client didn't send an empty string. In this case the server might be violating the spec regardless of whether it proceeds or returns an error to the client.

This issue could be worked around. During signup you can disallow creation of any user whose username contains only spaces. Even if the spec doesn't contain a single error message suitable for that you could still fall back to simply reporting that this particular username is in use. During login you can then safely report to the user that the username is incorrect, since you know that you wouldn't create it in the first place.

If you decide that removing trailing spaces is a good idea, then the next question is whether to extend that to removing all spaces. The other answers already contain arguments for and against this, so I have little to add there. The three options I see are:

• Silently remove the spaces
• Preserve the spaces
• Keep the spaces such that john doe and johndoe are two different usernames.

Depending on what systems the username is used in behind the scenes, there may be technical reasons to avoid keeping the spaces. For example it would be very inconvenient to have a space in a username on a unix system because there are scenarios where a space is used as a separator to indicate where the end of the username is and other text starts.