Login Page Design Patterns: What to Choose and What Each One Costs

Most people do not fail at the login page because they typed their password wrong. They fail because they cannot remember which of the four buttons they used last time.

That is the design problem. A returning user arrives at a screen offering a password field, a "Continue with Google" button, a "Continue with Apple" button and an "Email me a link" option, and has to recall a decision they made once, eighteen months ago, without thinking about it. Every additional method on the screen makes the first visit easier and the fifth visit harder.

Four patterns, and what each one assumes

A login page is a bet about what the user can be relied on to have with them.

Password. Assumes they have a password manager, or a password they reuse. Still the default, still the only method that works with no second device and no network round trip beyond the form post.

Magic link. Assumes they have access to the inbox on the device they are currently using. Removes the password entirely, and with it the reset flow. The cost is a context switch: the user leaves your login screen, goes to mail, comes back — and on mobile, often comes back inside an in-app browser with no session, which is where this pattern breaks most visibly.

One-time code. Assumes a phone number or an authenticator app. The user types the code instead of leaving to click one, so they stay on your screen, which is why it survives the in-app-browser problem that magic links hit. NIST's digital identity guidelines treat SMS delivery as a restricted authenticator (usable, but with a documented risk the verifier is expected to acknowledge), so a code sent by text is a weaker choice than the same code from an app.

Federated sign-in. Assumes an existing account with Google, Apple, Microsoft or similar. Fastest path on first visit and the one that generates the least support load, because the identity provider absorbs the reset, the lockout and the second factor. The cost lands later, in the account-selection amnesia above, and in the users who cannot tell you which email address is behind their Google account.

For a consumer product the default is the password field with correct autocomplete attributes plus one federated button. Everything past that is a support-cost trade, and you should be able to name which cohort it buys before you ship it.

Identifier-first, and what it buys

The pattern that reduces the amnesia is identifier-first: ask for the email address on screen one, then show only the method that account actually uses on screen two. Google's sign-in works this way, and so do most enterprise products, because it is the only layout that can route a single email to a password, an SSO redirect or a passkey without asking the user to know which they have.

The tradeoff is an extra screen for everyone, including the large majority who would have been fine with a combined form. It earns that screen back when you support SSO and consumer accounts side by side, when you are migrating users from passwords to passkeys and need to show each cohort a different thing, and once your login section has accumulated more than about three sign-in methods.

If none of those apply, a single-screen form with the password field and one or two federated buttons is still the right login user interface. Identifier-first solves a routing problem.

The password field

Autocomplete attributes. The login form needs autocomplete="username" on the identifier and autocomplete="current-password" on the password. A signup or change-password form uses autocomplete="new-password", which is what tells a password manager to offer a generated one. These tokens are defined in the HTML specification and are the mechanism every browser and password manager keys off. Getting them wrong is the single most common reason a login page silently stops autofilling.

Paste. Allow it. The UK's National Cyber Security Centre published guidance specifically telling sites to stop blocking paste in password fields, on the grounds that blocking it pushes users toward shorter, memorable, reused passwords. NIST's guidelines say the same thing from the other direction: verifiers should permit paste, to support password managers.

Show-password. Offer a temporary reveal. NIST recommends that the verifier offer an option to display the masked secret, because masking increases typing errors without meaningfully protecting a person who is alone with their own screen. Implement it as a toggle on the field with a real accessible name. An icon with no name is the same defect as any other unlabelled icon-only control, covered in our guide to ARIA labels.

Composition rules. Do not enforce them at login, obviously, but also reconsider them at signup. Current NIST guidance drops the mixed-character-class requirements and the mandatory periodic rotation that most products inherited from the older version of the same document, in favour of a long minimum and a check against known-breached passwords.

WCAG 2.2 moved the floor

WCAG 2.2, a W3C Recommendation since October 2023, added Success Criterion 3.3.8, Accessible Authentication (Minimum), at Level AA. It says that if a step in your authentication process relies on a cognitive function test — remembering a password, transcribing a code, solving a puzzle, identifying characters in an image — you must provide at least one of: an alternative method that does not rely on one, a mechanism to assist the user in completing it, object recognition, or identification of non-text content the user provided.

Supporting password managers is not a nicety any more. The "mechanism to assist" route is explicitly satisfied by letting a password manager fill the field, which means the autocomplete attributes and the paste behaviour above are load-bearing for AA conformance. A login page that blocks paste and mislabels its fields has removed the assistance mechanism and now has to satisfy the criterion some other way.

The other consequence is that character-transcription CAPTCHAs fail. So does any "type the third and fifth character of your memorable word" pattern, which is still common in UK banking. The object-recognition exception is why image CAPTCHAs ("select all the buses") survive at AA, and Level AAA's 3.3.9 removes even that.

Login and signup on one screen

A single form with a mode toggle (tabs, or a link that swaps "Sign in" for "Create account") is compact and the most likely to produce a wrong-mode submission, because the fields look identical in both states. If you build this, change the submit button label and the heading together, and set the autocomplete token per mode.

Separate pages with a prominent cross-link is the more forgiving pattern, and the one most sign up form examples worth copying use. The cost is a page load for anyone who guessed wrong; the benefit is that autofill, password-manager save prompts and browser history all behave predictably, because each URL means exactly one thing.

Deferred account creation — let people use the product, ask for credentials at the point where an account becomes necessary — is not a login page pattern at all, and it is usually the change with the biggest payoff. Baymard's recurring cart-abandonment research puts forced account creation among the leading reasons people abandon a purchase, and Nielsen Norman Group has made the same argument about login walls in general: a wall placed before any value has been delivered gets treated as a cost with no visible benefit. If you can move the login screen to a point where the user already has something to lose, do that before optimising the screen itself.

Error messages and the enumeration tradeoff

Here the usability answer and the security answer genuinely conflict, and the conflict is usually settled by whoever happened to write the string.

The helpful message is specific: "No account found for that email." The problem is that a specific message turns your login page into an account-enumeration oracle — anyone can test an email address and learn whether it is registered. OWASP's authentication guidance is direct about this: return an identical, generic failure ("Login failed; invalid user ID or password") regardless of which part was wrong, and keep response times consistent so timing does not leak the same fact.

What you can do without leaking anything:

• Be specific about format failures, client-side, before submission. "That does not look like an email address" reveals nothing.
• Be specific about lockout, once the user has already proved they know the password is wrong several times.
• Preserve the identifier field on failure. Clearing it is a small cruelty with no security benefit.
• Say which method the account uses after successful authentication, in account settings, where enumeration is no longer a risk.

Password reset carries the same constraint, and it is the one that most often ships broken: the reset request should respond identically whether or not the address exists, which means the confirmation screen has to be worded to cover both cases. "If an account exists for that address, we have sent a reset link" is awkward, and it is the version that does not leak. The follow-up matters too: a clear password change successfully message on return, and a session that is already signed in when the user lands.

On a phone

Set type="email" and inputmode="email" on the identifier so the keyboard shows an @. Set autocomplete="one-time-code" on an OTP field so iOS and Android offer the code from the incoming SMS without a trip to the messages app. Then check the whole flow inside an in-app browser. That is the webview that opens when someone taps your link from Instagram or Slack, and it is where magic links and federated redirects fail while working perfectly in Safari.

A checklist

Run an existing login page against this list. Items 1, 2 and 6 are the ones that need a browser and a real inbox to check; the rest are readable off the screen.

1. Autocomplete tokens correct on every field, per mode (username, current-password, new-password, one-time-code).
2. Paste allowed in every credential field.
3. Show-password toggle present, with an accessible name.
4. No character-transcription test anywhere in the flow (WCAG 2.2 SC 3.3.8).
5. Generic, timing-consistent failure message; identifier preserved.
6. Reset request response identical for existing and non-existing addresses.
7. Successful reset lands the user signed in, not back at the login form.
8. Total sign-in methods on screen: three or fewer, or identifier-first.
9. The whole flow tested once inside an in-app browser.
10. Error and empty states deliberately written, held to the same standard as the rest of your interface copy.

Frequently asked questions

What is the best login page design?

A password field with correct autocomplete attributes plus one federated option covers most consumer products; switch to identifier-first once you are past three methods. If you are choosing a fourth, choose a passkey rather than another social button — WebAuthn conditional mediation puts passkeys in the same browser autofill dropdown the password already uses, so it adds a method without adding a button to the screen.

Should the login page and signup be on the same screen?

Separate URLs with a clear cross-link is the safer default. The mechanism behind that is the browser's save-password prompt, which fires on a form submission that navigates: a single-screen toggle that submits over fetch and never changes the URL can swallow the prompt entirely, so a new user finishes signup with nothing saved. If you keep the toggle, update the document title and the autocomplete token together with the visible label.

Are magic links better than passwords?

They remove the password and the reset flow, and they add a context switch. The specific failure is cross-browser: the session starts in the in-app webview where the user requested the link, the mail client opens the link in the system default browser, and the two do not share cookies, so the user lands signed out on a page telling them they are signed in. One-time codes avoid it, because nothing has to be clicked in a second application. Whichever you pick, make the link or code single-use and short-lived.

What does WCAG 2.2 require of a login screen?

Success Criterion 3.3.8, Accessible Authentication (Minimum), at Level AA: no step may rely on a cognitive function test unless you also provide an alternative, an assistance mechanism, object recognition, or recognition of user-provided content. Supporting password managers satisfies the assistance route, which is why correct autocomplete attributes and unblocked paste now carry conformance weight. 3.3.8 is new in 2.2 — a product last audited against WCAG 2.1 has never been tested for it, and the stricter 3.3.9 at AAA removes the object-recognition exception that keeps image CAPTCHAs alive at AA.

Why is my login page not autofilling?

Check the autocomplete attributes first: the identifier needs autocomplete="username" and the password autocomplete="current-password", and a login form marked new-password will prompt to generate instead of fill. If the tokens are right and it still fails, check that both fields sit inside the same <form> element and that the password field is a real input type="password" — a custom component that fakes masking with a text input and a CSS font is invisible to every password manager.

Should login errors say which field was wrong?

No, for credential failures. OWASP recommends an identical generic message regardless of whether the identifier or the password was wrong. The part teams miss is that the same discipline has to cover every endpoint that touches an account — registration, reset request, and any "check availability" call on the signup form leak the same fact more cheaply than the login form does, and all of them need rate limiting for the answer to stay expensive. Format validation before submission and lockout notices after repeated failures are safe to be specific about.

Take it further

The UX Clarity framework reads a product's error and empty states as evidence, and a Full UX Audit runs the same pass across your forms, empty states and failure paths. The wider set of patterns this one sits inside is collected under interaction design, and the field-level accessibility work continues in user interface design principles and patterns.

Sources: WCAG 2.2 — SC 3.3.8 Accessible Authentication (Minimum) · HTML Standard — Autofill field names · NIST SP 800-63B — Digital Identity Guidelines, Authentication · NCSC — Let them paste passwords · OWASP — Authentication Cheat Sheet · NN/g — Login Walls Stop Users in Their Tracks · Baymard Institute — Cart Abandonment Rate Statistics.

Want to know which of the ten items above your product currently fails? Apply for a Full UX Audit →