A lot of sites today don't have a username, just a "login email".

If a user opened an account as [email protected], and are now trying to login using [email protected] - should we accept this login as true? Should we just convert the email to lower case before storing and validating it?

4 Answers 4


Yes, you should accept it as a login but internally lowercase it to rule out matching problems in your database and to ensure you don't have unintended duplicates. If the user makes a typo or simply prefers to write [email protected], why not go ahead and let them? It doesn't affect you if you don't let it. :-)

Gmail does something similar. You can register an email address with a . in it and Gmail just ignores that for its internal email address. So you can get [email protected] and that's effectively the same email address as [email protected]. Back in 2004 when Gmail launched, I found this to be an especially user friendly feature of their email service and few competing services have yet to implement it themselves.

The important lesson here is that you shouldn't allow your internal application architecture to surface to the end user unless it benefits them in someway. If you can keep it invisible, do it.

Edit: concerning case sensitivity, here's what About.com has to say:

But Case Typically Does Not Matter

Since the case sensitivity of email addresses can create a lot of confusion, interoperability problems and widespread headaches, it would be foolish to require email addresses to be typed with the correct case. Hardly any email service or ISP does enforce case sensitive email addresses, returning messages whose recipient's email address was not typed correctly (in all upper case, for example).

This means that

  • it does not typically matter what case you type an email address in when you send a message (If the recipient did give you an email address with distinct case, preserve it, however.)
  • and you should always only use lower case characters when creating a new email address to rule out any confusion.

So if you want to comply with the email RFC, don't follow my advice. If you know what email addresses will be used in your system (for instance, for an intranet for your company), I would just lowercase everything.

  • From a pure 'User Experience' point of view I would totally agree. Otherwise you'll have to label all the email fields with 'Caution: This is CASE SENSITIVE' and other such instructions that would annoy the user. Also, I believe that RFC 5321 is trying to discourage sensitivity of case anyway: tools.ietf.org/html/rfc5321: "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive."
    – JonW
    Commented Feb 3, 2012 at 9:03
  • Case is rarely a matching issue in databases; every common SQL engine comes with case sensitive matching off by default. There's still no reason I can imagine to store it case sensitive though; for displaying the email I'd just always lowercase it and not sweat what the user enters in though.
    – Zelda
    Commented Feb 3, 2012 at 14:39
  • 7
    Why lowercase the email? If you need to show it you would not be displaying the case that they recognise. According to your own reasoning you should keep your functionality invisible, so why not store the case they entered but make your checks (and uniqueness) case insensitive?
    – JamesRyan
    Commented Sep 27, 2013 at 9:47

Sounds like this question has mixed results. The de facto standard is to treat local mailboxes as case insensitive, but the official standard says case matters (though even the official standard mentions the de facto standard).

As other people have pointed out, it is possible that [email protected] and [email protected] are two different people, and both of them want to use your site. But on the other hand, it is far more likely that [email protected] and [email protected] are in fact the same person. If they type it one way one time, and another way another time, you probably want to let them in either way.

I'd suggest keeping track of both. Since using case insensitivity is so widespread, take their sign up email address and make it lower case. Whenever they try to log in, convert that to lowercase as well, for comparison purposes, when you go to see if the user exists. As far as sign up and sign in go, do a case insensitive comparison. If the person signs up as [email protected], you'll still want to allow them to sign in later with [email protected] or [email protected].

But you should also keep track of the email address that they signed up with in a case sensitive fashion. Any time you send an email to them, be sure to send it with that original casing. This allows the email server to handle it however it feels like it needs to. So even though the person may always be signing in to your site with [email protected], if they signed up as [email protected], you'll always send email to [email protected], just to be safe.

Some day, the de facto standard and the official standard will hopefully be the same. It's too bad we have to deal with this issue at all.

A couple of related side notes. The domain name (after the '@' sign) is always considered case insensitive, so you can always treat that in the same way. Second, just as important as the case sensitivity issue, you want to also be sure your site accepts all legal email addresses, which includes allowing all symbols that are allowed in email addresses. It is really frustrating for users who enter their legal email address, only to have the system say "the character '!' is not allowed." The standard defines what is allowed, but Wikipedia also has a good summary of this.

  • 2
    This answer is the closest to what the standard actually requires of SMTP servers - "The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts." The system can do whatever it wants to for login ids (and should probably ensure unique case insensitive ids), but if the system is going to use the email address to send via SMTP then it MUST preserve the case.
    – studgeek
    Commented Apr 2, 2018 at 19:04

No. The local part of an email address must be treated as case-sensitive.

For example, [email protected] and [email protected] could specify different mailboxes. If you converted the email to lower case, [email protected] would be unable to use your site. Also, if a [email protected] mailbox existed, it would receive any emails your site should have sent to [email protected].

After [email protected] had created an account, one could create a [email protected] email account at the same mail service and use a password reset to use [email protected]'s account at your site.

  • 6
    Technically true although it also goes on to say However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Thus providing case insensitivity would be the desirable course of action, while enforcing the case sensitvity would be just unnecessary. Commented Feb 3, 2012 at 9:13
  • @Roger Attrill See my edits about how one could reset the password of an account whose login/email address had upper case characters in a case-sensitive mail service. Commented Feb 3, 2012 at 9:33
  • This could be a good reason to reject the "login email" concept. Another would be that it enforces "one account per email" as a technical matter without considering whether this is a desired policy or not.
    – Random832
    Commented Feb 3, 2012 at 14:13


I would never do that -- cannot say all mail IDs are going to stay case-agnostic. At some point you may have to rework the logic, and anything else dependent on it, if things do change.

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.