Forgot Password Page Design
A forgot password page is where locked-out users decide whether to recover their account or leave. The best ones ask for one thing (an email), explain what happens next, and never reveal whether an account exists.
By Mohamed Farhan · Updated Oct 19, 2026
Reset your password
Enter your account email and we'll send you a reset link.
Remembered it? Back to sign in
Inside the example
The live example above is plain HTML with Tailwind utility classes, so you can paste it into any Tailwind project. It uses type sizes text-lg (18px), text-sm (14px) and spacing p-6 (24px), mt-1 (4px), mt-5 (20px), mt-1.5 (6px), px-3 (12px), py-2 (8px), mt-4 (16px), px-4 (16px), constrained by max-w-sm. Everything sits on a 4px grid, which keeps rhythm consistent when you adapt it.
Colors use Tailwind's neutral stone scale so the pattern stays brand-agnostic. Swap stone-900 for your primary color on the main action, keep body text dark and check contrast after any change.
Anatomy
- 1.Heading
- Plain language like 'Reset your password', not 'Account recovery'.
- 2.One-line explanation
- Tell users you will email a reset link.
- 3.Email field
- Pre-filled if the user typed an email on the login screen.
- 4.Primary action
- 'Send reset link' rather than a generic 'Submit'.
- 5.Way back
- A clear link back to sign in.
- 6.Confirmation state
- A screen that says what to do next and how long the link lasts.
Common variations
- Email link reset is the most common: the user enters an email and receives a link to a page where they set a new password.
- One-time code reset sends a short numeric code instead of a link. It works better on mobile because users do not have to switch apps and come back through a browser.
- Magic link sign-in skips the reset entirely and logs the user in from an email link. Many products offer it alongside password reset as a faster way back in.
- SMS reset uses a phone number instead of email. It is convenient but less secure, so it is usually combined with other verification.
States to design
- Request: email field and send button, with the email pre-filled if known.
- Sending: a disabled button with a short loading indicator to prevent double submissions.
- Sent: a neutral confirmation that does not reveal whether the account exists, plus the expiry time and a resend option.
- Expired or used link: a clear message and a one-click way to request a new link.
- Set new password: password field with visible requirements, show/hide toggle and a confirmation of success that signs the user in or sends them to sign in.
A walkthrough
Maya opens a project tool she has not used for months and cannot remember her password. On the sign-in screen she taps 'Forgot password?'. Because she already typed her email, the reset screen shows it pre-filled, so she only has to press 'Send reset link'.
The next screen says a link is on its way if an account exists, that it expires in 30 minutes, and that the email comes from the product's support address. She switches to her mail app, finds it and taps the button. The new-password screen lists the rules before she types, so her first attempt works, and she lands back in her dashboard with a short confirmation. A few seconds later a second email tells her the password changed, just in case it was not her.
How different products use it
Consumer apps usually optimize for speed: the email is pre-filled, the confirmation screen offers to open the mail app, and the new-password screen signs the user straight back in. The goal is to recover a user before they give up.
B2B and SaaS products often route resets through single sign-on. If a company uses SSO, the forgot password link should explain that the password is managed by the employer and point to the right identity provider instead of sending an email that will never arrive.
Banking, healthcare and other sensitive products add extra verification, such as a one-time code to a registered phone or security checks, and always notify the user by email after the password changes.
Visual design guidelines
Keep the reset screens visually identical to the sign-in screen: same card, same width (about 360 to 420px), same button style. Users should feel they never left the login flow. Use one input, one primary button and one text link. Leave generous space above the heading so the form sits in the visual center of the viewport, and keep the confirmation screen as light as possible, ideally just a heading, one sentence and a resend link.
Best practices
Do
- Carry over the email the user already typed on the login form.
- Show the same confirmation whether or not the email exists, to prevent account enumeration.
- Say how long the link is valid and suggest checking spam.
- Offer a resend option after a short delay.
Don't
- Do not ask security questions before sending a link.
- Do not tell users 'No account found for this email'.
- Do not log the user in automatically from the reset link without setting a new password.
On mobile
On mobile, people often request the reset link and then switch to their email app, so the flow must survive context switching. Keep the confirmation screen simple, support opening the link in the app through deep links where possible, and consider one-time codes with the autocomplete="one-time-code" attribute so the code can be filled from the keyboard suggestion.
Common mistakes
- Revealing whether an account exists, which lets attackers check which emails are registered.
- Sending users to a dead end when a link has expired, instead of offering a new one.
- Hiding password rules until after an error, which makes users guess.
- Logging out other sessions silently without telling users, which confuses people on other devices.
Edge cases to plan for
- The user signed up with Google or Apple. Tell them they do not have a password and offer the right social sign-in button.
- The email is mistyped. Show the address on the confirmation screen so users can spot typos.
- Multiple reset requests. Only the newest link should work, and the screen should say so.
- The link is opened on a different device. It should still work, then sign in on that device.
Accessibility checklist
- Label the email field with a visible label, not only a placeholder.
- Move focus to the confirmation message after submitting.
- Use autocomplete="email" so password managers and browsers can help.
Implementation notes
Generate single-use, time-limited tokens and store only a hash of them. Rate-limit reset requests per email and per IP. After a successful reset, invalidate existing sessions or offer to, and send a notification email that the password changed so users can react if it was not them.
In your design system
In a design system, the reset flow should be built entirely from existing pieces: the auth card layout, text input, primary button, inline link and alert components. Add a 'success' and 'info' alert variant if you do not already have them, and a password input with show/hide and requirement hints. Because the flow is rarely touched, keeping it on shared components prevents it from drifting out of date when the rest of the product changes.
How to measure whether it works
Track how many users start a reset, how many open the email, and how many complete a new password. A big drop between sending and opening suggests deliverability issues (spam folders, slow delivery); a drop between opening and completing suggests problems with the new password step. Also watch support tickets mentioning login problems.
Pre-launch checklist
Microcopy you can use
A step-by-step design process
- Map the whole flow first: request, email, set new password, success. Most problems happen between screens, not on them.
- Reuse the sign-in layout so the reset screens feel like part of the same place.
- Design the email with the same care as the screens: a clear subject line, one button and the expiry time.
- Design the expired-link screen, which is the most commonly forgotten state.
- Write the password rules and show them before the user types, not after an error.
- Test on a phone, switching between the mail app and the browser, to catch context-switching problems.
Usability test tasks
Before shipping, run a short usability test with five or so people from your audience. Give them tasks rather than instructions and watch where they hesitate:
- Reset your password starting from the sign-in page.
- Find the reset email and say how long the link is valid.
- Use an expired link and recover without help.
- Set a new password that meets the rules on the first try.
Key terms
- Account enumeration: An attack that checks which emails are registered by watching how a site responds.
- Reset token: A single-use, time-limited secret embedded in the reset link.
- Magic link: An email link that signs the user in directly without a password.
- OTP: A one-time passcode sent by email or SMS.
Writing the copy
Write like a calm helper, not a security system. Avoid words like 'invalid', 'failed' and 'unauthorized' on the request screen. Use the user's language: 'Reset your password', 'Check your email', 'Set a new password'. On the confirmation screen, name the sender and subject line of the email so users know what to look for, and mention the spam folder once, briefly.
Prompts to generate variations
If you use an AI UI generator such as Inspo AI, these prompts are a good starting point for exploring variations of this pattern:
- Design a forgot password flow for a fintech app with request, check-your-email and set-new-password screens, matching a minimal sign-in page.
- Create a mobile-first password reset flow using a 6-digit one-time code with autofill and a resend timer.
- Design an expired reset link screen with a friendly message and a one-tap way to request a new link.
Related patterns
Reset screens share their layout with sign-in and sign-up, so design them together with the login page and signup page. Error states follow the same rules as error messages in any form.
Generate this pattern for your product
Inspo AI designs the full pattern with every state, grounded in how real products solve it, and exports React + Tailwind.
Sources and further reading
- WAI-ARIA Authoring Practices Guide · Accessible keyboard and screen reader patterns for UI components.
- WCAG 2.1: Non-text Contrast · Contrast requirements for buttons, borders and icons.
- WCAG 2.1: Use of Color · Why color should never be the only way information is shown.
- Nielsen Norman Group articles · Usability research on interface patterns.
More UI patterns
Questions people ask
What should a forgot password page include?
A clear heading, a single email field, a 'Send reset link' button, a link back to sign in, and a confirmation screen explaining what happens next.
Should I tell users if their email is not registered?
No. Showing the same confirmation for every email prevents attackers from discovering which emails have accounts.
How long should a password reset link last?
Commonly 15 to 60 minutes. Tell users the exact time on the confirmation screen.
Should a password reset log the user in?
Many products sign users in after they set a new password, which reduces friction. If security is critical, send them to sign in with the new password instead.
Is a one-time code better than a reset link?
Codes are easier on mobile because users can type or autofill them without switching apps. Links are simpler on desktop. Many products offer both.
↘ Building Inspo AI | AI-Powered Design Research & Builder Platform | Design Engineer.