Forms
Login form design: 15 best practices for sign-in and sign-up forms
Login form design looks like a solved problem until you watch people use one: the wrong keyboard, a password manager that will not fill, an error that does not say what went wrong, a CAPTCHA they cannot solve. Each one locks out a customer who already wanted in. Here are the best practices, checked against current standards, for login and sign-up forms that are secure and easy.
Short answer
Good login form design lets a returning customer sign in quickly and safely on any device. It asks for as little as possible, uses visible labels and the right autocomplete values so password managers work, explains errors clearly, makes recovery easy, offers passwordless options and keeps account creation clearly separate from sign-in.
- Security and usability are mostly not opposites: current NIST guidance drops complex password rules and requires sites to allow password managers.
- Use one term, such as Sign in, and keep it clearly distinct from Create account.
- Placeholder text that disappears is not a label.
- Under WCAG 2.2, sign-in should not depend on solving a puzzle unless there is an alternative.
- Every failed sign-in is a customer who cannot buy, book or use what they paid for.
What is good login form design?
Good login form design lets a returning customer sign in quickly and safely, on any device, without thinking about it. It asks for as little as possible, works with password managers and passkeys, explains errors clearly, makes recovery easy and keeps account creation clearly separate. It is part of conversion, because every failed sign-in is a customer who cannot buy, book or use what they paid for.
Login forms are also where security and usability are most often treated as opposites. Current guidance shows they mostly are not. The NIST digital identity guidelines (SP 800-63B-4, 2025) drop the complex password rules that frustrate people, and require sites to allow password managers. The web accessibility standard, WCAG 2.2, adds a requirement that sign-in should not depend on solving a puzzle or remembering a code unless there is an alternative. Following both makes a login form easier and safer at the same time.
15 login form design best practices
The login form design best practices below fall into four groups: make sign-in easy to find and understand, build the form with the right HTML so browsers and password managers can help, handle passwords and errors the way current standards recommend, and offer recovery and passwordless options. Each one removes a reason a returning customer fails to get in.
-
Make sign-in easy to find
Put a "Sign in" link where people look for it, usually the top right of the header, on every page. On mobile, keep it visible or one tap away in the menu. Returning customers should never have to search for the way in.
-
Use one term, and keep it distinct from sign-up
Pick "Sign in" or "Log in" and use it on the link, the page heading and the button. Use clearly different words for registration, such as "Create account". "Login" and "Sign up" side by side, styled the same, is how people end up on the wrong form.
-
Ask only for what sign-in needs
An email address (or username) and a password, or just an email for a passwordless flow. Do not add account type selectors, extra security fields or marketing checkboxes to a sign-in form.
-
Use real labels, above the fields
Give each field a visible label that stays visible while typing, tied to the input in the HTML. Placeholder text that disappears is not a label: people forget what the field was for, and assistive tools may not announce it.
-
Set the right input types and autocomplete values
Use
type="email"for email fields so phones show the email keyboard. Addautocomplete="username"to the email or username field andautocomplete="current-password"to the sign-in password; useautocomplete="new-password"on sign-up and password change forms. This is how browsers and password managers know what to fill, as Google's sign-in form guide explains. -
Let password managers and paste work
NIST SP 800-63B-4 says sites shall allow password managers and autofill, and should allow pasting into password fields. Blocking paste pushes people toward short, reused passwords. Never disable autofill on a login form.
-
Offer a "show password" option
A toggle to reveal the password lets people check what they typed, which matters most on a phone keyboard. It is a better fix for typos than a second "confirm password" field.
-
Follow current password rules, not old ones
NIST SP 800-63B-4 sets a minimum of 15 characters when a password is the only factor and 8 when it is part of multi-factor sign-in, recommends allowing at least 64 characters, and says sites should not impose other composition rules (such as requiring a symbol) or force periodic changes. Instead, check new passwords against lists of common and breached passwords. Show the requirements before people type, not after they fail.
-
Write errors that help
Show errors next to the field, in plain words, and keep what the person typed in the email field. "Email or password is incorrect" is a common compromise between helping users and not revealing which emails have accounts. Whatever you choose, use the same approach on sign-in, sign-up and password reset.
-
Warn when Caps Lock is on
A small notice beside the password field when Caps Lock is active prevents one of the most common failed sign-ins. It costs little to build.
-
Make "Forgot password?" obvious and quick
Put the link directly beside or below the password field. The reset flow should ask only for the email, send a link that works on the device it is opened on, and let the person set a new password and sign in straight away.
-
Offer passwordless options
Passkeys let people sign in with their device's fingerprint, face or screen lock, using the WebAuthn standard. They resist phishing and remove forgotten passwords. One-time codes or sign-in links sent by email are another option. Offer them alongside passwords, so nobody is locked out during the change.
-
Offer third-party sign-in where your customers use it
"Continue with" buttons for widely used accounts can speed up sign-up and sign-in. Offer the ones your customers actually have, keep an email option, and remind people which method they used last time, so they do not create a second account.
-
Do not make people solve puzzles
WCAG 2.2 success criterion 3.3.8 (Accessible Authentication, Minimum) says an authentication step should not require a cognitive function test, such as remembering a password or solving a puzzle, unless an alternative or assistance is available. Allowing password managers and paste counts as assistance. Use rate limiting and invisible bot detection first, and show a challenge only when activity looks suspicious.
-
Design for thumbs and small screens
Make inputs and buttons large and well spaced. WCAG 2.2 sets 24 by 24 CSS pixels as the minimum target size at level AA and 44 by 44 at level AAA. Make the sign-in button full width on mobile, and make sure the keyboard does not cover it.
What to put on a login page, and what to leave off
A login page has one job: get a returning customer into their account. Everything on it should serve that job, so the layout is short. Put the form at the top, the help a struggling user needs right beside it, and nothing that pulls attention away from signing in.
- A short heading that says where they are, such as "Sign in to your account".
- The sign-in options in order of preference: passkey or third-party buttons if you offer them, then the email and password form.
- The form, with the forgot password link beside the password field and the sign-in button full width on mobile.
- A clear route to create an account, visually separate from the sign-in button.
- Help: a link to support for people who cannot get in, and links to the privacy policy and terms.
Leave off promotions, newsletter signups, autoplaying media and anything else that loads slowly or competes with the button. If the login is a modal on top of another page, make sure it can be closed, works with a keyboard and does not lose what the person was doing before.
Login and sign-up form fields: the HTML that makes them work
Login and sign-up forms look similar but need different HTML, because browsers and password managers treat them differently. A sign-in form should fill a saved password; a sign-up form should suggest a new strong one. The right attributes tell them which is which.
| Field | Sign-in form | Sign-up form |
|---|---|---|
type="email", autocomplete="username" | type="email", autocomplete="username" | |
| Password | type="password", autocomplete="current-password" | type="password", autocomplete="new-password" |
| One-time code | autocomplete="one-time-code", numeric keyboard | Same, if you verify by code |
| Show password | Yes | Yes, instead of a confirm field |
| Button label | Sign in | Create account |
| Secondary links | Forgot password? Create account | Already have an account? Sign in |
Sign-up form best practices that raise registrations
A sign-up form converts when creating an account feels quick and worth it. Ask for the minimum to create the account, explain the benefit next to the form, and collect everything else after the person is in. The best sign-up form is sometimes no sign-up form at all: let people buy as guests and offer an account afterwards.
- Avoid forced registration. On stores, guest checkout with an optional account after purchase removes a common reason to abandon.
- Ask for less. Email and password, or email only. Name, company and preferences can come later, in onboarding.
- Say what the account gives them, such as order tracking, saved carts or a free trial, beside the form.
- Show password requirements up front, and confirm each one as it is met.
- Verify email without blocking. Let people start using the account while the confirmation email is on its way, where the product allows it.
- Do not ask security questions. NIST SP 800-63B-4 says sites shall not prompt people to use knowledge-based questions, such as the name of a first pet, when choosing passwords.
- Keep consent honest. Marketing checkboxes start unticked, with plain wording.
Longer registrations, such as applications or onboarding with several questions, can work better split into steps; see multi-step forms.
What to avoid when designing login forms
Most login form problems come from old security habits and from copying patterns without testing them. These are the ones that lock out the most real customers.
- Blocking paste or autofill in password fields.
- Complex composition rules such as "one symbol, one number, one capital".
- Forced password changes on a schedule, without evidence of compromise.
- Visible CAPTCHAs on every attempt.
- Placeholder text instead of labels.
- Sign-in and sign-up forms that look identical, side by side.
- Errors that clear the whole form, or appear only after reloading.
- Password hints and security questions.
- Very short sessions for low-risk sites, forcing frequent sign-ins.
- Sign-in buried in a menu on mobile.
Security and usability: where login form design trade-offs really are
Security and usability on a login form agree more often than they conflict. Password managers, passkeys and breached-password checks are both safer and easier. The real trade-offs are few, and each one is a choice to make with your security team rather than a default to copy.
| Choice | Usability | Security |
|---|---|---|
| Allow password managers and paste | Better | Better: longer, unique passwords |
| Passkeys | Better: no password to remember | Better: resistant to phishing |
| Breached-password check instead of composition rules | Better | Better |
| Rate limiting instead of a visible CAPTCHA | Better | Similar, when combined with bot detection |
| Error says the email has no account | Better | Worse: reveals which emails are registered |
| Long "remember me" sessions | Better | Worse on shared devices |
| Multi-factor sign-in | Slightly worse: an extra step | Much better |
Login forms, password managers and AI agents
A login form built with standard HTML and autocomplete values works with every tool a person might use to sign in: browsers, password managers, screen readers and, increasingly, AI assistants that act for them. A form built from custom widgets, with fake fields and puzzles, breaks all of them at once.
Signing in is also where AI agents should be most careful, and where site owners should be too. Do not weaken security to let automated tools in. Do make sure the legitimate path is standard: real form fields, standard autocomplete values, passkey support and clear errors. That helps the person and any tool acting with their permission, without giving anyone a shortcut around your protections.
How to measure whether your login form works
Measure a login form by how many sign-in attempts succeed, how many people reset their password, and how many start but do not finish sign-up. Add these as events in your analytics and watch them by device. A rise in password resets or failed attempts after a change is an early warning.
- Sign-in success rate: successful sign-ins divided by attempts.
- Password reset rate: resets requested per sign-in attempt, and how many are completed.
- Sign-up completion rate: accounts created divided by sign-up forms started.
- Support contacts about access, by topic.
- Session recordings of failed attempts, to see what went wrong.
Login form design checklist
Run this login form design checklist on a phone and on a laptop, signed out, with your password manager on.
- Sign in is easy to find on every page, on mobile too
- One term for signing in, clearly different from creating an account
- Only the fields sign-in needs
- Visible labels above fields, tied to the inputs
- Email field uses type email; autocomplete values are set correctly
- Password managers fill the form and paste works
- Show password toggle on every password field
- No composition rules or forced changes; breached passwords are blocked
- Errors appear next to the field and keep what was typed
- Caps Lock warning on the password field
- Forgot password link beside the password field, with a short reset flow
- Passkeys or one-time codes offered where the platform supports them
- No visible puzzle by default; rate limiting and bot detection instead
- Large, well-spaced targets and a full-width button on mobile
- Sign-in success, reset and sign-up completion rates are tracked
Related guides
Login form design FAQ
What makes a good login form design?
Good login form design asks for as little as possible, usually an email or username and a password, with clear labels, the right autocomplete attributes so password managers work, a show password option, helpful error messages, an obvious forgotten password link and a clearly separate route to create an account.
What is the best practice for password validation?
Follow NIST SP 800-63B-4 (2025): set a minimum length (15 characters when a password is the only factor, 8 when it is part of multi-factor sign-in), accept long passwords and spaces, check new passwords against lists of common or breached passwords, and do not force mixes of character types or periodic changes.
What should I include on my login page?
Include a clear heading, an email or username field, a password field with a show option, a sign-in button, a forgotten password link, a link to create an account, any passwordless or third-party sign-in options you support, and links to help and the privacy policy. Leave out marketing that competes with signing in.
How do you design a secure login page that also gets a lot of sign-ups?
Make the secure path the easy path. Let password managers and paste work, offer passkeys or email codes, check passwords against breached lists instead of adding complex rules, rate limit failed attempts behind the scenes instead of showing puzzles, and keep the sign-up form short with clear benefits next to it.
Should a login form use a CAPTCHA?
Avoid a visible CAPTCHA as the default. Puzzles block real users, and WCAG 2.2 says an authentication step should not require a cognitive test unless an alternative is offered. Use rate limiting, invisible bot detection and multi-factor sign-in first, and show a challenge only when activity looks suspicious.
Should I use Sign in or Log in on a login form?
Either works. What matters is consistency and a clear difference from account creation. Pick one term, such as Sign in, and use it on the link, the page heading and the button. Use clearly different words, such as Create account, for registration.
Should login error messages say whether an account exists?
It is a trade-off. A message saying the email has no account helps real users but also tells attackers which emails are registered. Many sites use a general message such as Email or password is incorrect, and protect the account with rate limiting. Decide with your security team and be consistent across sign-in, sign-up and password reset.
What are passkeys and should my login form support them?
Passkeys let people sign in with their device's fingerprint, face or screen lock instead of a password, using the WebAuthn standard. They resist phishing and remove forgotten passwords. If your platform supports them, offer passkeys alongside existing sign-in methods rather than replacing everything at once.