Lets say we are designing a new website's registration form.

Would I need to provide a space for a username, or should I simply require an email address?

Are there any serious issues with either of these methods?

5 Answers 5


Depending on your target audience ('normal', very tech savvy, or originating from social networks) either:

  • email address & password (the email address is the username)


Both have their issues.

In some audiences email addresses change a lot. You need a good account recovery mechanism, preferably with an option to add multiple email addresses to each account. But still, email addresses as usernames are superior to self-chosen usernames because people can remember them, and using just email + password simplifies the signup process.

OpenID, Facebook Connect etc are great. But the indirection of "I'm on Site B, and I can't log in. I need to go to Site A to check my credentials" is not understood by the mass market yet. OpenID works great with very tech-savvy audiences though, as illustrated by the Stack Exchange sites...

Conclusion: You need to carefully consider your target audience, and if possible, run a hallway usability test of different authentication mechanisms.

  • +1 Target audience is key, but Facebook Connect seems iffy for anything that is intended to stay live for the next 5 years (remember MySpace? Friendster?)
    – danlefree
    Sep 17, 2010 at 22:57
  • @danlefree: Very valid point, I agree. Personally I wouldn't be happy with Facebook Connect unless may target audience is ~100% Facebook users (maybe a social networking viral game, or something..). Not everyone is on Facebook yet, and the federated login model isn't something the average user is trained on yet, as mentioned...
    – user1857
    Sep 17, 2010 at 23:10
  • 1
    Older people (Well, I'd say anyone 18+) tend not to change their email accounts so often, so if you're targeting adults then the email address could be a good one to use. Due to my personal hatred of usernames, we switched our model to email address only and it's worked really well. We target professionals though, who tend to use their work email addresses to register. A well-thought-out registration form is just as important as chosing your login mechanism though. We dropped ours from 20+ fields to just 5 (including 'repeat password') and our registrations tripled overnight. Sep 18, 2010 at 1:30

There's issues with both, believe it or not.

People change their email almost constantly, it seems. The younger they are, the worse it is. For this reason, it's tough to tie accounts to email. However, emails seem far easier for people to remember than usernames.

Usernames are great in that they don't often change, but people do often forget them. Then you have to deal with both a password retrieval system AND a username retrieval system. Double the work, half the fun.

I personally do both when I'm doing a site without some sort of open id system. I collect both, store both in the DB, then search based on the entered login value to see which one they intended to use. Obviously, this means no @ symbols in usernames. However, it makes it pretty easy for my users to remember at least one of two options. For retrieval I use a challenge system, as I'm wary of emails for validation purposes. Hackers can get emails...they may not know what a person's first dog's name or favorite car is.

OpenId seems to make a lot of this argument less important. It's a good thing to check out.


It can also depend on how you store your user information. For instance, if you use a database that has the primary key as the username then you probably wouldn't want to use email address as the username, since if the user changes their email address then this will change the primary key (and screw up any foreign key references).

  • 1
    Thanks for contributing. Respectfully I don't quite agree. First, implementation details should preferably not 'shine through' in the UI. Second, if there isn't a natural key (fx email) that seems perfectly suited and immutable, then a surrogate key (fx auto-incrementing INT) should always be used as primary key. This software design rule is really important, and can avoid lots of trouble. :-)
    – user1857
    Sep 18, 2010 at 23:22
  • 1
    @ Jesper - I totally agree. But sometimes as a developer you don't have control over how data is stored (you may be interfacing with an external data provider). For instance, if you were using ASP.NET and using the default membership provider then usernames would be the primary key and you wouldn't be able to change this. Just something to consider...
    – Dan Diplo
    Sep 19, 2010 at 14:10

You may wish to have a username field if you wish users to hide their email address or real name from other users/visitors.

It's often called a nickname in these cases instead, and can sometimes be changed on the fly without affecting the user's login.

I think the answer depends on what you're going to do with the information you collect e.g. not sending the user emails - don't ask for an email address, not displaying user information, don't collect a nickname etc.


Username, email addresses and OpenId have their pros and cons.

But never call it username and require that to be an email address!

When registring I enter one of my prefered usernames as username. And it makes me angry when - after clicking OK - I get a message that the username is not a valid email address.

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.