A sign-in screen is two inputs and a button, and it is still the screen most products get wrong, because almost none of the difficulty is visual. It is in the order of the buttons, the attributes on the fields, what the error says, and what happens on the fourth attempt.
Here are the layouts, and then the parts that decide whether anyone gets in.
The layouts
Centred card. The default, and correct for most products. Sign In by Hossain Jahed is the most-bookmarked one in the catalogue, Sign In Card by Jatin Yadav and Modern & Stunning sign in by preetsuthar17 are the neighbouring takes, and Login Form by Le Thanh is the plain version.
Split screen. Form on one side, image or product shot on the other. AuthFuse by Hossain Jahed and Travel Connect Signin by Mridul Dhamija are the shapes. It gives a marketing surface next to the form, and it costs the layout on a phone, where the panel has to disappear entirely rather than stack.
Full screen. Full Screen Signup by preetsuthar17. Right when sign-up is the whole product surface, wrong when the reader arrived from somewhere they want to return to.
Toggled. Auth Switch by AppVibed animates between sign-in and sign-up in place. It saves a navigation and it needs care: the two forms have different fields and different validation, and the transition must not leave a screen reader on a form that no longer exists.
The attributes that decide whether a password manager works
This is the highest-leverage part of the whole screen and it is four lines.
The email field needs type="email" and autocomplete="username". The password field needs autocomplete="current-password" on sign-in and new-password on sign-up. Both belong inside a real <form> with a submit button, so Enter submits and the manager knows where the boundary is. And a one-time code field needs autocomplete="one-time-code", which is what puts the SMS code above the keyboard.
Get these wrong and a password manager either fills the wrong field or does not offer to fill at all, which turns a two-second login into a manual retype on a phone.
The provider buttons
Put them above the form, not below. Someone who signed up with a provider is looking for that button, and finding it under a password field they cannot use is the most common friction in this screen.
Two more. Show which method the account already uses if you can, because "you signed up with Google" prevents the loop where someone resets a password that does not exist. And label the button with the provider's name, not just its logo.
The errors
Never say which half was wrong. "Email not found" tells an attacker that an address is registered. One message for both: "Email or password is incorrect."
Say what to do next. A failed login needs the reset link right there, not in the footer.
Rate limiting has to be explainable. The fourth attempt getting silently rejected is indistinguishable from a broken form. Say that it is temporary and roughly for how long.
Keep what they typed. Clearing the email field on a failed password is a small cruelty that doubles the retype.
The sign-up half
Three rules that change completion rates more than any layout.
Ask for as little as possible, and ask the rest later, which the onboarding guide covers. State the password requirements before submission rather than as an error afterwards, and check the entered password against them live. And skip the confirm-password field: it is a legacy of forms with no reveal control, and a visible toggle plus a reset flow solves the same problem with one field instead of two.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| shadcn/ui | Form, Input, Label and Button underneath any of these | No auth screens |
| An auth provider's components | The flows, the sessions and the provider buttons wired | Their look, and a dependency on their SDK |
| React Hook Form + a validator | Validation and error state | Not a visual layer |
| 21st | Finished cards, split screens and animated switches | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a sign-in screen, get the previews inline, and let the agent write the file.
Frequently asked
- Which attributes does a login form need?
- type="email" with autocomplete="username" on the email field, autocomplete="current-password" on sign-in and new-password on sign-up, everything inside a real form with a submit button, and autocomplete="one-time-code" on a verification field. Getting these wrong makes a password manager fill the wrong field or not offer at all.
- What should a failed login say?
- One message for both halves: email or password is incorrect. Saying which one was wrong tells an attacker whether an address is registered. Put the reset link right there rather than in the footer, keep what the reader typed, and if rate limiting kicks in, say it is temporary and roughly for how long.
- Where do social sign-in buttons go?
- Above the form. Someone who signed up with a provider is looking for that button, and finding it under a password field they cannot use is the commonest friction on this screen. Label it with the provider's name rather than only its logo, and show which method the account uses if you can.
- Do you still need a confirm-password field?
- No. It is a legacy of forms with no reveal control. A visible show-password toggle plus a working reset flow solves the same problem with one field instead of two, and it removes a step from the highest-friction screen in the product.