form best practices

If users ever need to log in to your site, then good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-in forms get high bounce rates. Each bounce could mean a lost and disgruntled user—not just a missed sign-in opportunity.

Try it! If you would prefer to learn these best practices with a hands-on tutorial, check out the Sign-in form best practices codelab. Here is an example of a simple sign-in form that demonstrates all of the best practices:


  • Use meaningful HTML elements: 

    , and 
  • Label each input with a  .

  • Use element attributes to access built-in browser features:  type name autocomplete required autofocus .

  • Give input  name  and  id  attributes stable values that don’t change between page loads or website deployments.

  • Put sign-in in its own 


  • Ensure successful form submission.

  • Use  autocomplete="new-password"  for the password input in a sign-up form, and for the new password in a reset-password form.

  • Use  autocomplete="current-password"  for a sign-in password input.

  • Provide Show password functionality.

  • Use  aria-label  and  aria-describedby  for password inputs.

  • Don’t double-up inputs.

  • Design forms so the mobile keyboard doesn’t obscure inputs or buttons.

  • Ensure forms are usable on mobile: use legible text, and make sure inputs and buttons are large enough to work as touch targets.

  • Maintain branding and style on your sign-up and sign-in pages.

  • Test in the field as well as the lab: build page analytics, interaction analytics, and user-centric performance measurement into your sign-up and sign-in flow.

  • Test across browsers and devices: form behaviour varies significantly across platforms.

This article is about frontend best practices. It does not explain how to build backend services to authenticate users, store their credentials, or manage their accounts. 12 best practices for user account, authorization and password management outlines core principles for running your own backend. If you have users in different parts of the world, you need to consider localizing your site’s use of third-party identity services as well as its content. There are also two relatively new APIs not covered in this article which can help you build a better sign-in experience:

  • Web OTP: to deliver one-time passcodes or PIN numbers via SMS to mobile phones. This can allow users to select a phone number as an identifier (no need to enter an email address!) and also enables two-step verification for sign-in and one-time codes for payment confirmation.

  • Credential Management: to enable developers to store and retrieve password credentials and federated credentials programmatically.

Use meaningful HTML

Use elements built for the job: 


Here’s the CSS to make the button look like plain text:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;

And the JavaScript for showing the password:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');

Here’s the end result:

 Sign-in form with Show password text ‘button’, in Safari on Mac and iPhone 7.

Make password inputs accessible

Use  aria-describedby  to outline password rules by giving it the ID of the element that describes the constraints. Screenreaders provide the label text, the input type (password), and then the description.

Eight or more characters with a mix of letters, numbers and symbols.

When you add Show password functionality, make sure to include an aria-label to warn that the password will be displayed. Otherwise users may inadvertently reveal passwords.

You can see both ARIA features in action in the following Glitch:

Creating Accessible Forms has more tips to help make forms accessible.

Validate in realtime and before submission

HTML form elements and attributes have built-in features for basic validation, but you should also use JavaScript to do more robust validation while users are entering data and when they attempt to submit the form. Warning: Client-side validation helps users enter data and can avoid unnecessary server load, but you must always validate and sanitize data on your backend. Step 5 of the sign-in form codelab uses the Constraint Validation API (which is widely supported) to add custom validation using built-in browser UI to set focus and display prompts. Find out more: Use JavaScript for more complex real-time validation.

Analytics and RUM

“What you cannot measure, you cannot improve” is particularly true for sign-up and sign-in forms. You need to set goals, measure success, improve your site—and repeat. Discount usability testing can be helpful for trying out changes, but you’ll need real-world data to really understand how your users experience your sign-up and sign-in forms:

  • Page analytics: sign-up and sign-in page views, bounce rates, and exits.

  • Interaction analytics: goal funnels (where do users abandon your sign-in or sign-in flow?) and events (what actions do users take when interacting with your forms?)

  • Website performance: user-centric metrics (are your sign-up and sign-in forms slow for some reason and, if so, what is the cause?).

You may also want to consider implementing A/B testing in order to try out different approaches to sign-up and sign-in, and staged rollouts to validate the changes on a subset of users before releasing changes to all users.

General guidelines

Well designed UI and UX can reduce sign-in form abandonment:

  • Don’t make users hunt for sign-in! Put a link to the sign-in form at the top of the page, using well-understood wording such as Sign In, Create Account or Register.

  • Keep it focused! Sign-up forms are not the place to distract people with offers and other site features.

  • Minimize sign-up complexity. Collect other user data (such as addresses or credit card details) only when users see a clear benefit from providing that data.

  • Before users start on your sign-up form, make it clear what the value proposition is. How do they benefit from signing in? Give users concrete incentives to complete sign-up.

  • If possible allow users to identify themselves with a mobile phone number instead of an email address, since some users may not use email.

  • Make it easy for users to reset their password, and make the Forgot your password? link obvious.

  • Link to your terms of service and privacy policy documents: make it clear to users from the start how you safeguard their data.

  • Include the logo and name of your company or organization on your signup and sign-in pages, and make sure that language, fonts and styles match the rest of your site. Some forms don’t feel like they belong to the same site as other content, especially if they have a significantly different URL.

Keep learning

  • Create Amazing Forms

  • Best Practices For Mobile Form Design

  • More capable form controls

  • Creating Accessible Forms

  • Streamlining the Sign-in Flow Using Credential Management API

  • Verify phone numbers on the web with the Web OTP API

Photo by Meghan Schiereck on Unsplash.


欢迎关注「  字节前端 ByteFE