Help your users sign up, sign in and manage their account details with
minimum fuss.
 Sam Dutton [X](https://twitter.com/sw12) [GitHub](https://github.com/samdutton) [Mastodon](https://techhub.social/@samdutton) [Bluesky](https://bsky.app/profile/samdutton.bsky.social) [Homepage](https://samdutton.com)
[Video](https://www.youtube.com/watch?v=Ev2mCzJZLtY)
If users ever need to sign in to your site, then good sign-up form design is
critical. This is especially true for people on poor connections, on mobile, in
a hurry, or under stress. Poorly designed sign-up forms get high bounce rates.
Each bounce could mean a lost and disgruntled user---not just a missed sign-up
opportunity.
> [!TIP]
> **Tip:** If you would prefer to learn these best practices with a tutorial, take the [Sign-up form best practices codelab](https://web.dev/articles/codelab-sign-up-form-best-practices.md.txt).
Here is an example of a sign-up form that demonstrates all of the best practices:
> [!CAUTION]
> **Caution:** This document covers form best practices. To learn sign-up using a third-party identity provider (federated login) or show how to build backend services to authenticate users, store credentials, and manage accounts, read instructions for [secure credential management with federated login](https://web.dev/articles/security-credential-management-retrieve-credentials.md.txt#federated_login) [12 best practices for user account, authorization and password management](https://cloud.google.com/blog/products/gcp/12-best-practices-for-user-account) outlines core backend principles for managing user accounts.
## Checklist
- [Avoid sign-in if you can](https://web.dev/articles/sign-up-form-best-practices.md.txt#no-forced-sign-in).
- [Make it obvious how to create an account](https://web.dev/articles/sign-up-form-best-practices.md.txt#obvious-account-creation).
- [Make account details accessible](https://web.dev/articles/sign-up-form-best-practices.md.txt#obvious-account-details).
- [Cut form clutter](https://web.dev/articles/sign-up-form-best-practices.md.txt#cut-clutter).
- [Consider session length](https://web.dev/articles/sign-up-form-best-practices.md.txt#session-length).
- [Help password managers securely suggest and store passwords](https://web.dev/articles/sign-up-form-best-practices.md.txt#help-password-managers).
- [Don't allow compromised passwords](https://web.dev/articles/sign-up-form-best-practices.md.txt#no-compromised-passwords).
- [Allow password pasting](https://web.dev/articles/sign-up-form-best-practices.md.txt#allow-password-pasting).
- [Never store or transmit passwords in plain text](https://web.dev/articles/sign-up-form-best-practices.md.txt#salt-and-hash).
- [Don't force password updates](https://web.dev/articles/sign-up-form-best-practices.md.txt#no-forced-password-updates).
- [Make it easier to change or reset passwords](https://web.dev/articles/sign-up-form-best-practices.md.txt#password-change).
- [Enable federated login](https://web.dev/articles/sign-up-form-best-practices.md.txt#federated-login).
- [Make account switching simple](https://web.dev/articles/sign-up-form-best-practices.md.txt#account-switching).
- [Offer multi-factor authentication](https://web.dev/articles/sign-up-form-best-practices.md.txt#multi-factor-authentication).
- [Take care with usernames](https://web.dev/articles/sign-up-form-best-practices.md.txt#username).
- [Test in the field as well as the lab](https://web.dev/articles/sign-up-form-best-practices.md.txt#analytics-rum).
- [Test on a range of browsers, devices and platforms](https://web.dev/articles/sign-up-form-best-practices.md.txt#test-platforms).
## Avoid sign-in if you can
Before you implement a sign-up form and ask users to create an account on your site, consider
whether you really need to. Wherever possible you should avoid gating features behind login.
The best sign-up form is no sign-up form!
By asking a user to create an account, you come between them and what they're trying to achieve.
You're asking a favor, and asking the user to trust you with personal data. Every password and item
of data you store carries privacy and security "data debt", becoming a cost and liability for
your site.
If the main reason you ask users to create an account is to save information between navigations or
browsing sessions, [consider using client-side storage](https://web.dev/articles/storage-for-the-web.md.txt) instead. For shopping
sites, forcing users to create an account to make a purchase is cited as a major reason for shopping
cart abandonment. You should [make guest checkout the default](https://web.dev/articles/payment-and-address-form-best-practices.md.txt#guest-checkout).
## Make sign-in obvious
Make it obvious how to create an account on your site, for example with a **Login** or **Sign in**
button at the top right of the page. Avoid using an ambiguous icon or vague wording ("Get on board!",
"Join us") and don't hide login in a navigational menu. The usability expert Steve Krug summed up
this approach to website usability: [Don't make me think!](https://uxplanet.org/dont-make-me-think-20-wise-thoughts-about-usability-from-steve-krug-876b563f1d63) If you need to
convince others on your web team, use [analytics](https://web.dev/articles/sign-up-form-best-practices.md.txt#analytics-rum) to show the impact of different
options.
 Make sign-in obvious. An icon may be ambiguous, but a **Sign
in** button or link is obvious.
> [!NOTE]
> **Note:** You may be wondering whether to add a button (or link) to create an account and another one for existing users to sign in. Many popular sites now display a single **Sign in** button. When the user taps or clicks, they also get a link to create an account, if necessary. That's a common pattern now and your users likely understand it, but you can use [interaction analytics](https://web.dev/articles/sign-up-form-best-practices.md.txt#analytics-rum) to monitor whether or not a single button works best.
 The Gmail sign-in page has a link to create an account.
At window sizes larger than shown here, Gmail displays a **Sign in** link and a **Create an
account** button.
Make sure to link accounts for users who sign up using an identity provider,
such as Google, and who also sign up using email and password. That's
straightforward if you can access a user's email address from the profile data
from the identity provider, and match the two accounts. The code shown here
show how to access email data for a Google Sign-in user.
```javascript
// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
var profile = auth2.currentUser.get().getBasicProfile();
console.log(`Email: ${profile.getEmail()}`);
}
```
### Make account details accessible
Once a user has signed in, make it clear how to access account details. In
particular, make it obvious how to [change or reset passwords](https://web.dev/articles/sign-up-form-best-practices.md.txt#password-change).
## Cut form clutter
In the sign-up flow, your job is to minimize complexity and keep the user
focused. Cut the clutter. This is not the time for distractions and temptations.
Don't distract users from completing sign-up.
On sign-up, ask for as little as possible. Collect additional user data (such as name and address)
only when you need to, and when the user sees a clear benefit from providing that data. Bear in mind
that every item of data you communicate and store incurs cost and liability.
Don't double up your inputs just to make sure users get their contact details right. That slows down
form completion and doesn't make sense if form fields are autofilled. Instead, send a confirmation
code to the user once they've entered their contact details, then continue with account creation
once they respond. This is a common sign-up pattern: users are used to it.
You may want to consider password-free sign-in by sending users a code every time they sign in on
a new device or browser. Sites such as Slack and Medium use a version of this.
Password-free sign-in on medium.com.
As with federated login, this has the added benefit that you don't have to
manage user passwords.
## Consider session length
Whatever approach you take to user identity, you need to make a careful
decision about session length: how long the user remains logged in, and what
might cause you to log them out.
Consider whether your users are on mobile or desktop, and whether
they are sharing on desktop, or sharing devices.
> [!NOTE]
> **Note:** You can get around some of the issues of shared devices by enforcing re-authentication for sensitive features, for example when a purchase is made or an account updated. You can find out more about ways to implement re-authentication from the codelab [Your First WebAuthn App](https://codelabs.developers.google.com/codelabs/webauthn-reauth/#0).
## Help password managers securely suggest and store passwords
You can help third-party and built-in browser password managers suggest and
store passwords, so that users don't need to choose, remember or type passwords
themselves. Password managers work well in modern browsers, synchronizing
accounts across devices, across platform-specific and web apps and
for new devices.
This makes it extremely important to code sign-up forms correctly. In
particular, use the correct autocomplete values. For sign-up forms use
`autocomplete="new-password"` for new passwords, and add autocomplete values
to other form fields wherever possible, such as `autocomplete="email"`
and `autocomplete="tel"`. You can also help password managers by using
different `name` and `id` values in sign-up and sign-in forms, for the
`form` element itself, as well as any `input`, `select` and `textarea` elements.
You should also use the appropriate
[`type` attribute](https://developer.mozilla.org/docs/Web/HTML/Element/input/email)
to provide the right keyboard on mobile and enable basic built-in validation by
the browser. You can find out more from
[Payment and address form best practices](https://web.dev/articles/payment-and-address-form-best-practices.md.txt#make_it_easy_for_users_to_enter_data).
> [!NOTE]
> **Note:** [Sign-in form best practices](https://web.dev/articles/sign-in-form-best-practices.md.txt) has lots more tips on how to improve form design, layout and accessibility, and how to code forms correctly in order to take advantage of built-in browser features.
## Ensure users enter secure passwords
Enabling password managers to suggest passwords is the best option, and you
should encourage users to accept the strong passwords suggested by browsers
and third-party browser managers.
However, many users want to enter their own passwords, so you need to implement
rules for password strength. The US National Institute of Standards and
Technology explains
[how to avoid insecure passwords](https://pages.nist.gov/800-63-3/sp800-63b.html#5-authenticator-and-verifier-requirements).
> [!WARNING]
> **Warning:** Sign-up forms on some sites have password validation rules that don't allow the strong passwords generated by browser and third-party password managers. Make sure your site doesn't do this, since it interrupts form completion, annoys users, and requires users to make up their own passwords, which may be less secure than those generated by password managers.
### Don't allow compromised passwords
Whatever rules you choose for passwords, you should never allow passwords that
have been
[exposed in security breaches](https://haveibeenpwned.com/PwnedWebsites).
Once a user has entered a password, you need to check that it's not a password that's already been
compromised. The site [Have I Been Pwned](https://haveibeenpwned.com/Passwords) provides an API for password
checking, or you can run this as a service yourself.
Google's Password Manager also lets you
[check if any of your existing passwords have been compromised](https://passwords.google.com/checkup).
If you do reject the password that a user proposes, tell them specifically why
it was rejected.
[Show problems inline and explain how to fix them](https://baymard.com/blog/inline-form-validation),
as soon as the user has entered a value, not after they've submitted the sign-up
form and had to wait for a response from your server.
Be clear why a password is rejected.
### Allow password pasting
Some sites don't allow text to be pasted into password inputs.
Disallowing password pasting annoys users, encourages passwords that are
memorable (and therefore may be easier to compromise) and, according to
organizations such as the UK National Cyber Security Centre, may actually
[reduce security](https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords).
Users only become aware that pasting is disallowed *after* they try to paste
their password, so
[disallowing password pasting doesn't avoid clipboard vulnerabilities](https://github.com/OWASP/owasp-masvs/issues/106).
### Never store or transmit passwords in plain text
Make sure to [salt and hash](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#Use_a_cryptographically_strong_credential-specific_salt) passwords---and [don't try to invent your own hashing algorithm](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html)!
### Don't force password updates
[Don't force users to update their passwords arbitrarily.](https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers:%7E:text=Verifiers%20SHOULD%20NOT%20require%20memorized%20secrets%20to%20be%20changed%20arbitrarily%20(e.g.%2C%20periodically).)
Forcing password updates can be costly for IT departments, annoying to users,
and [doesn't have much impact on security](https://pages.nist.gov/800-63-FAQ/#q-b05).
It's also likely to encourage people to use insecure memorable passwords, or
to keep a physical record of passwords.
Rather than force password updates, you should monitor for unusual account
activity and warn users. If possible, you should also monitor for passwords
that become compromised because of data breaches.
You should also provide your users with access to their account login history,
showing them where and when a login happened.
 [Gmail account activity page](https://support.google.com/mail/answer/45938 "Find out how to view Gmail account activity.").
### Make it easy to change or reset passwords
Make it obvious to users where and how to update their account password. On
some sites, it's surprisingly difficult.
You should, of course, also make it easy for users to reset their password if
they forget it. The Open Web Application Security Project provides detailed
guidance on
[how to handle lost passwords](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html).
To keep your business and your users safe, it's especially important to help users change their
password if they discover that it's been compromised. To make this easier, you should add a
[`/.well-known/change-password`](https://w3c.github.io/webappsec-change-password-url/) URL to your
site that redirects to your password management page. This enables password managers to navigate
your users directly to the page where they can change their password for your site. This feature is
now implemented in Safari, Chrome, and is coming to other browsers. [Help users change passwords
easily by adding a well-known URL for changing passwords](https://web.dev/articles/change-password-url) explains how to
implement this.
You should also make it easy for users to delete their account.
## Offer third-party login
Many users prefer to sign in to websites using an email address and password
sign-up form. However, you should also enable users to sign in using a
third-party identity provider, also known as federated login.
 WordPress login page, with Google and Apple login options.
This approach has several advantages. For users who create an account using
federated login, you don't need to ask for, communicate, or store passwords.
You may also be able to access additional verified profile information from
federated login, such as an email address---which means the user doesn't have to
enter that data and you don't need to do the verification yourself. Federated
login can also make it much easier for users when they get a new device.
[Integrating Google Sign-In into your web app](https://developers.google.com/identity/gsi/web/guides/overview)
explains how to add federated login to your sign-up options. [Many other](https://en.wikipedia.org/wiki/Federated_identity#Examples) identity platforms are available.
> [!NOTE]
> **Note:** "First-day experience" when you get a new device is increasingly important. Users expect to sign in from multiple devices including their phone, laptop, desktop, tablet, TV, or from a car. If your sign-up and sign-in forms aren't seamless, this is a moment where you risk losing users, or at least losing contact with them until they get set up again. You need to make it as quick and easy as possible for users on new devices to get up and running on your site. This is another area where federated login can help.
## Make account switching simple
Many users share devices and swap between accounts using the same browser. Whether users access
federated login or not, you should make account switching simple.
 Account switching on Gmail.
## Offer multi-factor authentication
Multi-factor authentication means ensuring that users provide authentication in more than one way.
For example, as well as requiring the user to set a password, you might also enforce verification
using a one-time-passcode sent by email or an SMS text message, or by using an app-based one-time
code, security key or fingerprint sensor. [SMS OTP best practices](https://web.dev/articles/sms-otp-form.md.txt) and
[Enabling Strong Authentication with WebAuthn](https://developer.chrome.com/blog/webauthn)
explain how to implement multi-factor authentication.
> [!CAUTION]
> **Caution:** While using SMS for two-factor authentication is better than a password alone, it's less effective than other approaches, such as using an authenticator app or email. For more information, see the [NIST recommendations](https://www.nist.gov/blogs/cybersecurity-insights/questionsand-buzz-surrounding-draft-nist-special-publication-800-63-3) on digital identity guidelines.
You should certainly offer (or enforce) multi-factor authentication if your site handles personal or
sensitive information.
## Take care with usernames
Don't insist on a username unless (or until) you need one. Enable users to sign up and sign in with
only an email address (or telephone number) and password---or [federated login](https://web.dev/articles/sign-up-form-best-practices.md.txt#federated-login)
if they prefer. Don't force them to choose and remember a username.
If your site does require usernames, don't impose unreasonable rules on them, and don't stop users
from updating their username. On your backend you should generate a unique ID for every user account,
not an identifier based on personal data such as username.
Also make sure to use `autocomplete="username"` for usernames.
> [!CAUTION]
> **Caution:** As with personal names, it's best to allow usernames to include [Unicode letters](https://web.dev/articles/payment-and-address-form-best-practices.md.txt#unicode-matching). Don't restrict to characters in the [Latin alphabet](https://developer.mozilla.org/docs/Web/JavaScript/Guide/Regular_Expressions/Character_Classes#Types:%7E:text=Latin%20alphabet).
## Test on a range of devices, platforms, browsers and versions
Test sign-up forms on the platforms most common for your users. Form element
functionality may vary, and differences in viewport size can cause layout
problems. BrowserStack enables [free testing for open source projects](https://www.browserstack.com/open-source) on a range of devices and browsers.
## Implement analytics and Real User Monitoring
You need [field data as well as lab data](https://web.dev/articles/how-to-measure-speed.md.txt#lab_data_vs_field_data)
to understand how users experience your sign-up forms. Analytics and [Real User Monitoring](https://developer.mozilla.org/docs/Web/Performance/Rum-vs-Synthetic#Real_User_Monitoring)
(RUM) provide data for the actual experience of your users, such as how long sign-up pages take to
load, which UI components users interact with (or not) and how long it takes users to complete
sign-up.
- **Page analytics** : [page views, bounce rates and exits](https://analytics.google.com/analytics/academy/course/6) for every page in your sign-up flow.
- **Interaction analytics** : [goal funnels](https://support.google.com/analytics/answer/6180923) and [events](https://developers.google.com/analytics/devguides/collection/gtagjs/events) indicate where users abandon the sign-up flow and what proportion of users click buttons, links, and other components of your sign-up pages.
- **Website performance** : [user-centric metrics](https://web.dev/articles/user-centric-performance-metrics.md.txt) can tell you if your sign-up flow is slow to load or [visually unstable](https://web.dev/articles/cls.md.txt).
Small changes can make a big difference to completion rates for sign-up forms. Analytics and RUM
enable you to optimize and prioritize changes, and monitor your site for problems that aren't
exposed by local testing.
## Keep learning
- [Sign-in form best practices](https://web.dev/articles/sign-in-form-best-practices.md.txt)
- [Payment and address form best practices](https://web.dev/articles/payment-and-address-form-best-practices.md.txt)
- [Create Amazing Forms](https://web.dev/learn/forms.md.txt)
- [Best Practices For Mobile Form Design](https://www.smashingmagazine.com/2018/08/best-practices-for-mobile-form-design/)
- [More capable form controls](https://web.dev/articles/more-capable-form-controls.md.txt)
- [Creating Accessible Forms](https://webaim.org/techniques/forms/)
- [Streamlining the Sign-up Flow Using Credential Management API](https://developer.chrome.com/blog/credential-management-api)
- [Verify phone numbers on the web with the WebOTP API](https://web.dev/articles/web-otp)