Build a sign-in form that follows best practice

Use cross-platform browser features to build sign-in forms that are secure, accessible and easy to use.

If users ever need to sign 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 customer and a disgruntled user—not just a missed sign-in opportunity.

How to implement

Outlined below are the most important guidelines for building successful sign-in forms.

Use meaningful, valid HTML

Make the most of the elements and attributes built for creating forms:

• <form>, <input>, <label>, and <button>
• type, autocomplete, and inputmode

These enable built-in browser functionality, improve accessibility, and add meaning to markup.

Use the <label> element to label form fields for data entry

To label an <input>, <select>, or <textarea>, use a <label>. Associate a label with an input by giving the label's for attribute the same value as the input's id.

Make the most of HTML attributes

Make it easy for users to enter data, by using the appropriate <input> element <type> attribute to provide the right keyboard on mobile and enable basic built-in validation by the browser.

Always use type="email" for email addresses and type="tel" for phone numbers.

Every <input>, <select>, and <textarea> element SHOULD have an appropriate autocomplete attribute, to improve accessibility and help users avoid re-entering data.

Username and email inputs hold identifiers, not prose. Add spellcheck="false" so the browser does not rewrite them into something the account does not match. autocorrect and autocapitalize are always disabled for input type="email", but are required for non-email usernames.

Make buttons helpful

Use <button> for buttons. You can also use <input type="submit">, but don't use a div or some other random element acting as a button. Button elements provide accessible behaviour, built-in form submission functionality, and can easily be styled.

Give each form submit button a value that says what it does. Use a clear, recognizable label. For example, use Sign In rather than Continue or Submit.

Use a single name input where possible

Allow your users to enter their name using a single input, unless you have a good reason for separately storing given names, family names, honorifics, or other name parts. Using a single name input makes forms less complex, enables cut-and-paste, and makes autofill simpler.

Allow international names. For validation, avoid using regular expressions that only match Latin characters. Latin-only excludes users with names or addresses that include characters that aren't in the Latin alphabet. Allow Unicode letter matching instead—and ensure your backend supports Unicode securely as both input and output. Unicode in regular expressions is well supported by modern browsers.

Show sign-in progress

For each step towards sign-in, use page headings and descriptive button values that make it clear what needs to be done now, and what the next step is.

Use the enterkeyhint attribute on form inputs to set the mobile keyboard enter key label. For example, use enterkeyhint="previous" and enterkeyhint="next" within a multi-page form, enterkeyhint="done" for the final input in the form, and enterkeyhint="search" for a search input.

Help users avoid re-entering sign-in data

Make sure to add appropriate autocomplete values in sign-in forms.

This enables browsers to help users by securely storing sign-in details and correctly entering form data. Without autocomplete, users may be more likely to keep a physical record of sign-in details, or store sign-in data insecurely on their device.

Validate carefully

Validate data entry both in realtime and before form submission. Use type="email" for email inputs — the browser will validate the format automatically. Add the required attribute to mandatory fields to prevent empty submissions.

Put sign-in in its own <form> element

Always use the <form> element when you're getting users to enter data

Don't wrap inputs in a <div> and handle input data submission purely with JavaScript. It's generally better to use a <form> element. This makes your site accessible to screenreaders and other assistive devices, enables a range of built-in browser features, makes it simpler to build basic functional sign-in for older browsers, and can still work even if JavaScript fails.

Don't double up inputs

Some sites force users to enter emails or passwords twice. That might reduce errors for a few users, but causes extra work for all users, and increases abandonment rates. Asking twice also makes no sense where browsers autofill email addresses or suggest strong passwords. It's better to enable users to confirm their email address (you'll need to do that anyway) and make it easy for them to reset their password if necessary.

Keep passwords private—but enable users to see them if they want

Passwords inputs should have type="password" to hide password text and help the browser understand that the input is for passwords. (Note that browsers use a variety of techniques to understand input roles and decide whether or not to offer to save passwords.)

You should add a Show password toggle to enable users to check the text they've entered—and don't forget to add a Forgot password link.

Give mobile users the right keyboard

Use <input type="email"> to give mobile users an appropriate keyboard and enable basic built-in email address validation by the browser… no JavaScript required!

If you need to use a telephone number instead of an email address, <input type="tel"> enables a telephone keypad on mobile. You can also use the inputmode attribute where necessary: inputmode="numeric" is ideal for PIN numbers.

Prevent mobile keyboard from obstructing the Sign in button

If you're not careful, mobile keyboards may cover your form or, worse, partially obstruct the Sign in button. Users may give up before realizing what has happened.

Where possible, avoid this by displaying only the email (or phone) and password inputs and Sign in button at the top of your sign-in page. Put other content underneath.

Help users to avoid re-entering data

You can help browsers store data correctly and autofill inputs, so users don't have to remember to enter email and password values. This is particularly important on mobile, and crucial for email inputs, which get high abandonment rates. There are two parts to this:

1. The autocomplete, name, id, and type attributes help browsers understand the role of inputs in order to store data that can later be used for autofill. To allow data to be stored for autofill, modern browsers also require inputs to have a stable name or id value (not randomly generated on each page load or site deployment), and to be in a <form> element with a submit button.
2. The autocomplete attribute helps browsers correctly autofill inputs using stored data.

For email inputs use autocomplete="username", since username is recognized by password managers in modern browsers—even though you should use type="email" and you may want to use id="email" and name="email". For password inputs, use the appropriate autocomplete value to help browsers differentiate between new and current passwords.

Use autocomplete="current-password" for an existing password

MANDATORY: Use autocomplete="current-password" for the password input in a sign-in form. This tells the browser that you want it to use the current password that it has stored for the site.

For a sign-in form:

<input type="password" autocomplete="current-password" id="current-password" …>

Enable the browser to suggest a strong password

Modern browsers use heuristics to decide when to show the password manager UI and suggest a strong password.

Built-in browser password generators mean users and developers don't need to work out what a "strong password" is. Since browsers can securely store passwords and autofill them as necessary, there's no need for users to remember or enter passwords. Encouraging users to take advantage of built-in browser password generators also means they're more likely to use a unique, strong password on your site, and less likely to reuse a password that could be compromised elsewhere.

Help save users from accidentally missing inputs

MANDATORY: Add the required attribute to both email and password fields. Modern browsers automatically prompt and set focus for missing data.

<input type="email" id="email" name="email" autocomplete="username" required>
<input type="password" id="password" name="password" autocomplete="current-password" required>

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. Users only become aware that pasting is disallowed after they try to paste their password, so disallowing password pasting doesn't avoid clipboard vulnerabilities.

Fallback strategies

Autofill is a progressive enhancement. In browsers that do not support autofill, users will simply need to manually enter their sign-in credentials. The semantic HTML constraints (such as type, inputmode, and required) will still function appropriately to validate user input and provide the correct virtual keyboards.