# auth.normalise-email
`normaliseEmail(" Alice@Example.COM ")` is `"Alice@example.com"`. Call it on
every address before it is stored and before it is looked up, at sign-up, at
login and anywhere else, so that one person's address has one spelling in the
database. It answers `null` when the trimmed text is not an address that
`validation.email` accepts, so a sign-up form or API can report the field in
the same step.
**What changes.** Leading and trailing ASCII whitespace (space, tab, line
feed, carriage return, form feed, vertical tab) is removed, since pasted
addresses often carry it. The domain is lower-cased: domain names are
case-insensitive (RFC 4343), so `Example.COM` and `example.com` are the same
mailbox host.
**What does not.** The local part, before the `@`, is kept exactly as typed.
RFC 5321 section 2.4 says it MAY be case-sensitive and that only the receiving
host can decide, so lower-casing it could, in principle, merge two people's
accounts. In practice nearly every provider treats it case-insensitively, so
`Alice@example.com` and `alice@example.com` will be two different accounts
here; an application that wants them merged should lower-case the whole
address itself and say so. Dots and `+tags` are also kept (`a.b+news@gmail.com`
is not rewritten to `ab@gmail.com`): that folding is one provider's rule, not
a property of email.
Non-ASCII whitespace such as a no-break space is not trimmed, and the address
is then refused, since `validation.email` accepts ASCII only. Internationalised
domains must arrive punycoded (`xn--...`).