Back to compare picker

Login vs Sign in vs Password input vs Session timeout warning vs Account creation

Choose login when the design problem is what happens after a user submits credentials: pending verification, success, generic failure, remaining attempts, throttling delay, lockout, unlock, support, audit notice, and session creation.

Decision dimensions

Dimension LoginSign inPassword inputSession timeout warningAccount creation
UI or UX UI + UX - Credential-verification attempt lifecycle and login outcome handlingUI + UX - Returning-account authentication and session start flowUI + UX - Authentication secret entry controlUI + UX - Authenticated-session expiry and reauthentication boundary warningUI + UX - Persistent account establishment flow
UI guidance Render login as the outcome-sensitive credential verification state: pending verification, neutral failure, remaining attempts or wait time when policy allows, throttling or lockout state, unlock or recovery route, and successful session-created confirmation.Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area.Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.Render account creation as a focused task with a clear reason for the account, one identifier path, new-credential fields, verification or activation state, existing-account route, and post-creation destination.
UX guidance Use login when users have already chosen an authentication route and submitted credentials or an authenticator output, and the product must explain the verification result safely.Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator.Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability.
Good UI After a failed login, the page keeps the email address, clears the password, shows Check your details and try again, gives 2 attempts remaining, and keeps forgot password and use passkey routes available.A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review.A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login.A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.A service lets users draft an application, then asks them to create an account to save and return later with email, new password, terms acknowledgement, and a clear activation message.
Bad UI The page says Password wrong for one email and No account found for another.A sign-in page has four equal buttons for sign in, create account, reset password, and browse plans, with no indication of the protected destination.A login form uses a normal text field named Password and leaves the secret visible on screen.The app logs out after 15 minutes with no countdown and clears a long form.A checkout asks for account registration before showing shipping cost or guest checkout even though the purchase can complete without an account.
Good UX A user mistypes the password twice, sees remaining attempts and a neutral account-details error, uses a passkey instead, and reaches the intended workspace with retry warnings cleared.A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation.A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history.A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft.
Bad UX A user gets locked out after repeated typos with no warning and no explanation of when to retry.A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context.A user cannot paste from a password manager and shortens the password to something easier to type.A user returns from a phone call to find the form gone and a generic access denied page.A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary.
Best fit Users have submitted credentials or authenticator output and need a safe verification result.Users need to access an existing account or protected destination.The user needs to enter an existing password, passphrase, or PIN-like memorized secret.An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access.
Avoid when The problem is choosing an authentication method or explaining why authentication is required before credentials are submitted.The user is creating a new account, choosing a new password, or verifying a new contact method.The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.There is no authenticated session boundary and the issue is ordinary navigation away.The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link.
Required state Ready-to-submit login state with chosen identifier and authenticator route.Initial sign-in state with service or destination context.Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.Active session with no warning.Need-for-account state explaining why an account is required or beneficial at this point.
Accessibility burden Announce verifying, failed-login, throttled, lockout, and success states without forcing focus away from the next useful action.Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts.Use a visible label that names the password purpose, such as Password or Current password.Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.Use a clear H1 such as Create an account and visible labels that say Create a password or Email address rather than ambiguous credential labels.
Common misuse Returning different messages for unknown account, wrong password, disabled account, or locked account.Using account-specific error messages that reveal whether an identifier exists.Using type text for passwords.Using a client-only timer that disagrees with the server session.Forcing accounts before users can evaluate a service or complete a one-off transaction.

Login

UI or UX
UI + UX - Credential-verification attempt lifecycle and login outcome handling
UI guidance
Render login as the outcome-sensitive credential verification state: pending verification, neutral failure, remaining attempts or wait time when policy allows, throttling or lockout state, unlock or recovery route, and successful session-created confirmation.
UX guidance
Use login when users have already chosen an authentication route and submitted credentials or an authenticator output, and the product must explain the verification result safely.
Good UI
After a failed login, the page keeps the email address, clears the password, shows Check your details and try again, gives 2 attempts remaining, and keeps forgot password and use passkey routes available.
Bad UI
The page says Password wrong for one email and No account found for another.
Good UX
A user mistypes the password twice, sees remaining attempts and a neutral account-details error, uses a passkey instead, and reaches the intended workspace with retry warnings cleared.
Bad UX
A user gets locked out after repeated typos with no warning and no explanation of when to retry.
Best fit
Users have submitted credentials or authenticator output and need a safe verification result.
Avoid when
The problem is choosing an authentication method or explaining why authentication is required before credentials are submitted.
Required state
Ready-to-submit login state with chosen identifier and authenticator route.
Accessibility burden
Announce verifying, failed-login, throttled, lockout, and success states without forcing focus away from the next useful action.
Common misuse
Returning different messages for unknown account, wrong password, disabled account, or locked account.

Sign in

UI or UX
UI + UX - Returning-account authentication and session start flow
UI guidance
Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area.
UX guidance
Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator.
Good UI
A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review.
Bad UI
A sign-in page has four equal buttons for sign in, create account, reset password, and browse plans, with no indication of the protected destination.
Good UX
A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation.
Bad UX
A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context.
Best fit
Users need to access an existing account or protected destination.
Avoid when
The user is creating a new account, choosing a new password, or verifying a new contact method.
Required state
Initial sign-in state with service or destination context.
Accessibility burden
Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts.
Common misuse
Using account-specific error messages that reveal whether an identifier exists.

Password input

UI or UX
UI + UX - Authentication secret entry control
UI guidance
Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.
UX guidance
Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.
Good UI
A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login.
Bad UI
A login form uses a normal text field named Password and leaves the secret visible on screen.
Good UX
A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history.
Bad UX
A user cannot paste from a password manager and shortens the password to something easier to type.
Best fit
The user needs to enter an existing password, passphrase, or PIN-like memorized secret.
Avoid when
The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.
Required state
Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
Accessibility burden
Use a visible label that names the password purpose, such as Password or Current password.
Common misuse
Using type text for passwords.

Session timeout warning

UI or UX
UI + UX - Authenticated-session expiry and reauthentication boundary warning
UI guidance
Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.
UX guidance
Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.
Good UI
A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.
Bad UI
The app logs out after 15 minutes with no countdown and clears a long form.
Good UX
A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.
Bad UX
A user returns from a phone call to find the form gone and a generic access denied page.
Best fit
An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.
Avoid when
There is no authenticated session boundary and the issue is ordinary navigation away.
Required state
Active session with no warning.
Accessibility burden
Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.
Common misuse
Using a client-only timer that disagrees with the server session.

Account creation

UI or UX
UI + UX - Persistent account establishment flow
UI guidance
Render account creation as a focused task with a clear reason for the account, one identifier path, new-credential fields, verification or activation state, existing-account route, and post-creation destination.
UX guidance
Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability.
Good UI
A service lets users draft an application, then asks them to create an account to save and return later with email, new password, terms acknowledgement, and a clear activation message.
Bad UI
A checkout asks for account registration before showing shipping cost or guest checkout even though the purchase can complete without an account.
Good UX
A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft.
Bad UX
A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary.
Best fit
Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access.
Avoid when
The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link.
Required state
Need-for-account state explaining why an account is required or beneficial at this point.
Accessibility burden
Use a clear H1 such as Create an account and visible labels that say Create a password or Email address rather than ambiguous credential labels.
Common misuse
Forcing accounts before users can evaluate a service or complete a one-off transaction.
Decision rules
  • Choose login when the design problem is what happens after a user submits credentials: pending verification, success, generic failure, remaining attempts, throttling delay, lockout, unlock, support, audit notice, and session creation.
  • Choose sign in when the design problem starts before credential submission: explaining why authentication is needed, choosing passkey, password, SSO, magic link, or recovery route, preserving the return destination, and routing between related flows.
  • Choose password input when the problem is only the existing-secret control, show and hide behavior, current-password autocomplete, paste, password-manager compatibility, or field-level secret handling.
  • Choose session timeout warning when the user is already authenticated and a server or policy boundary will expire or require reauthentication soon.
  • Choose account creation when the user is establishing a new account rather than verifying an existing authenticator during a login attempt.
  • A login attempt should preserve the entered identifier where appropriate, clear or protect secrets after failure, show neutral failure copy, and avoid revealing whether account existence, password, lockout, disabled state, or verification caused the outcome.
  • A login attempt can show remaining attempts, wait time, unlock route, or support route when policy allows, but should not create an easy denial-of-service or account enumeration signal.
  • A successful login should establish the session, reset retry counters where policy permits, record or expose security-relevant login status, and continue to the authenticated destination supplied by the sign-in journey.
  • Login throttling, bot checks, CAPTCHA, or lockout should be separate states with accessible alternatives rather than one unexplained disabled Sign in button.
Inspect live examples
Failure modes
  • The login result says password wrong for a real account and no account found for a fake account.
  • A user has one remaining attempt but the UI gives no warning, no wait time, and no recovery route before lockout.
  • The lockout message never explains when retry is possible, whether self-service unlock exists, or how to contact support.
  • A CAPTCHA is the only post-failure path and has no accessible or lower-friction alternative.
  • A successful login opens a session but leaves stale failed-attempt warnings, does not reset state, or hides a security notice users need.