Login and password reset forms - what to include and how to protect users

A visitor arrives at your site and clicks "Sign In." They expect a smooth login experience. Instead, they hit a form that frustrates them. Password requirements are hidden until submission. The password field is small and hard to type into. There is no "Show password" option, so they cannot verify what they typed. They get the password wrong. They click "Forgot Password" and land on a confusing reset flow. A few minutes later, they give up and never come back.

Login and password reset forms are critical touchpoints. These forms stand between a returning visitor and their account. If the experience is poor, they do not just leave. They assume your site is not trustworthy. This chapter covers how to build login and password reset forms that are secure, intuitive, and respect your user's time.

Which fields does a login form need?

A login form needs exactly three things. First, a way to identify who the person is. Second, a way to verify their identity. Third, a way to stay logged in. That means three fields at minimum.

The email field

Use email, not username. Email is simpler. Users forget usernames. They do not forget their email address. Make this field accept an email address and label it clearly as "Email address." Use HTML `type="email"` so mobile keyboards show the @ symbol and email validation happens automatically. In the HTML attribute, add `autocomplete="username"` so browsers and password managers know this is where the login identifier goes and can autofill it for users who have saved credentials.

The password field

Use `type="password"` so the text is hidden. Add `id="current-password"` and `autocomplete="current-password"` so password managers can identify this field and autofill saved passwords. Allow paste functionality. Security experts agree that disabling paste on password fields does not prevent attacks. It only frustrates people who use password managers.

Make the password field at least 10 characters wide visually. A small input feels cramped. Users doubt whether their long password will fit. A wider field builds confidence and reduces submission errors.

Show password toggle

Include a "Show password" or "Reveal password" toggle (usually an eye icon or checkbox). When enabled, the password field changes to `type="text"` so users can see what they typed. This is not a security risk. It is a usability feature that reduces submission errors and frustration. Users type passwords carefully and want to verify them before hitting submit.

Remember me checkbox (optional but recommended)

A "Remember me on this device" or "Keep me signed in" checkbox is optional, but it improves experience. When checked, the session lasts longer or the browser stores a persistent login token (securely). This means users do not have to log in every time they visit. For low-risk accounts, this is safe. For high-security accounts (financial, health, admin panels), skip this or require re-authentication for sensitive actions.

If you include a remember me checkbox, be explicit about what it does. "Remember me for 30 days" is clearer than just "Remember me."

Forgot password link

Place a "Forgot password?" link directly below the password field or to the right of it. This is not optional. Users forget passwords. Provide an obvious path to reset it. If they cannot find the link, they leave the site and may never return.

How should a password reset form work?

A password reset flow has multiple steps. Each step matters. Each step is a place where users can get confused and abandon.

Step one: Request email verification

The reset flow starts when a user clicks "Forgot password" on the login form. They land on a page that says something like "Enter your email address to reset your password." A single email field appears. That is all. No extra fields. No asking for username or security questions. Just the email.

The button should say something clear and action-oriented. "Send reset link" or "Get reset instructions" tells them what happens next. "Submit" is vague.

Step two: Send reset link via email

When they submit their email, your system immediately sends them a password reset email. The email should arrive within seconds, not minutes. Speed matters. If the email takes 10 minutes, users assume it did not work and try again, or worse, they leave.

The reset email contains a unique link (or a code they enter on the next page). That link should expire after a set time, usually 24 hours. A link that never expires is a security risk if someone gains access to their email.

Step three: Verify the link and show password reset form

When they click the reset link in the email, they arrive at the password reset form. This page should clearly confirm what is happening: "Reset your password" or "Create a new password." No confusion about whether they are in the right place.

Show the email address they are resetting the password for. "You are resetting the password for example@email.com." This reassures them they are resetting the correct account.

Step four: Set password requirements clearly before they submit

Display the password requirements on the reset form BEFORE they try to submit. Do not make them guess. "Your password must be at least 12 characters, include one uppercase letter, one number, and one special character." Be specific. Show examples of what qualifies.

A password strength indicator (a bar that shows weak, medium, strong) helps users understand if their password meets requirements without submitting and getting an error. Some users find this helpful. Some find it frustrating if the requirements are unclear. If you use a strength meter, pair it with explicit text requirements.

Step five: Password field and confirmation

Ask for a new password. Then ask them to confirm it by typing it again. This confirmation step catches typos. The downside is that a confirmation field adds friction. Research shows removing the password confirmation field increases completion rates. If you keep it, make both fields show a "Reveal password" toggle so they can verify both entries match before submitting.

Step six: Immediate confirmation and next steps

When they successfully reset their password, show a success message. "Your password has been reset. You can now sign in with your new password." Then provide a link back to the login form or a button that says "Go to login" so they do not have to navigate or search.

Also send them a confirmation email. "Your password was recently reset. If you did not do this, click here to secure your account." This alerts them if someone else reset their password and gives them a way to undo it.

Where do login forms go on your site?

Login forms are not decorative. They need to be findable without hunting.

Header or navigation

The most visible place is the header. A "Sign In" or "Log In" link (or button) in the top right of your site is where users expect it. When they click it, either take them to a dedicated login page or open a modal with the login form. Mobile users expect the sign in option in the hamburger menu. Never hide it behind layers of navigation.

Dedicated login page

Create a dedicated `/login` or `/sign-in` page. This page contains the login form, nothing else. No blog posts. No marketing copy. Just the form and any necessary help text. A clean, focused page converts better than embedding the login form on a general page.

Password reset page

The password reset form should live at a dedicated URL like `/reset-password` or `/forgot-password`. This page is only reachable from the login form or from a link in the reset email. It should not be indexed by search engines. Add `noindex` to this page in your HTML or robots.txt so Google does not try to rank it.

Common mistakes in login form design

Even well-intentioned login forms often have problems that hurt user experience.

Too many fields before login

Some sites ask for username, email, phone, and security answer on the login form itself. Do not do this. Login is not registration. Ask only for email and password. Everything else is extra friction.

Hidden or unclear password requirements

If password requirements are hidden until they submit, users get frustrated. They enter a password. They hit submit. An error appears: "Password must be 12 characters and include a number." Now they have to try again. Show requirements upfront.

No show password option

Users cannot see what they typed. They submit. They get it wrong. They try again. They get it wrong again. A simple toggle saves this frustration.

Confusing error messages

Never tell users "Invalid login." This does not help. Are they using the wrong email? Wrong password? Is the account not activated? Be specific. "No account found for this email address" or "Password is incorrect" tells them what to fix. Or if you want to be vague for security reasons, give them a recovery path. "Email and password do not match. Try again or reset your password."

Reset link expires too quickly

A reset link that expires in 15 minutes frustrates users. They check their email after work. The link is dead. They have to start over. Give them at least 24 hours.

Reset flow sends to a confusing page

Some reset flows send users to a page that does not clearly say what to do. They click the reset link. They land on a page with unclear text and no form. They think something went wrong. Make it obvious. "Reset your password for example@email.com" with a password field and submit button.

Security considerations for login and password reset

A login form is a security-critical part of your site. Protect it properly.

Use HTTPS for all login traffic

Your login page must be served over HTTPS, not HTTP. HTTPS encrypts the data in transit so hackers cannot read the email and password as it travels to your server. This is non-negotiable. If your site does not have an SSL certificate, get one. Most hosting providers provide free SSL certificates now.

Validate password strength on the server

Browser-side validation helps users, but do not rely on it alone. JavaScript validation can be bypassed. Validate the password on your server. Check that it meets your requirements. Only accept passwords that meet your strength standards.

Hash and salt passwords in your database

Never store passwords in plain text. Use a secure hashing algorithm (like bcrypt or Argon2) with salt. Even if someone breaches your database, they cannot read the passwords. A properly hashed password cannot be reverse-engineered into the original password.

Rate limit login attempts

If someone tries to log in 10 times in a minute, block them. Rate limiting prevents brute force attacks where hackers try thousands of password combinations. After a few failed attempts, pause for 15 minutes before allowing more tries.

Expire password reset tokens quickly

A password reset token that works for 24 hours is standard. Tokens that work for 7 days or longer increase the risk that a compromised email account leads to a compromised site account. Keep tokens short-lived.

Log login activity for fraud detection

Keep a record of successful and failed login attempts. If someone logs in from a new country or unusual time, flag it. Some systems send an email when an account logs in from a new device. This alerts the account owner if someone else accessed it.

Mobile login forms - what is different?

Mobile changes how login forms need to work.

Touch targets and button size

On mobile, fingers are not as precise as cursors. Buttons and input fields need to be larger. The submit button should be at least 44 pixels tall. Input fields should be tall enough for comfortable typing. Aim for 44 to 48 pixels in height.

Mobile keyboards and input types

Use `type="email"` for the email field. This tells mobile devices to show the email keyboard with @ and . symbols. Without it, users have to switch keyboard modes. Use `type="password"` for the password field so the keyboard matches. This small detail saves taps and frustration.

Autocomplete and password managers

Mobile browsers and password manager apps (like 1Password or Bitwarden) can autofill login credentials. Make sure your HTML attributes support this. Include `autocomplete="username"` on the email field and `autocomplete="current-password"` on the password field. This is a huge convenience on mobile where typing is slower.

Form layout on small screens

Stack fields vertically. Do not put email and password side by side on a mobile screen. One field per row. The form should use the full width with adequate margins. A form that feels cramped on mobile does not get completed.

Avoid mobile keyboard overlap

When the mobile keyboard appears, it covers half the screen. Make sure the login button is visible above the keyboard, or provide a way to dismiss the keyboard easily. Some sites show the button only after the keyboard closes. That frustrates users. Keep the button visible.

Frequently asked questions

How WEMASY helps with login and password reset forms

WEMASY's form builder supports secure login and password reset flows. Create a login form with email and password fields. Add a show password toggle with one click. Set password requirements (character length, uppercase, numbers, special characters). Use conditional logic to show a remember me checkbox or skip it based on your security needs. Connect to WEMASY's authentication system or integrate with external auth providers via API. WEMASY handles password hashing, rate limiting, and session management automatically. Password reset emails are sent securely from your domain. Reset tokens expire after 24 hours. See what is included in the WEMASY plans.