UX Patterns Guide
UI + UX Task And Workflow Patterns standard

Confirm email

Use a confirmation loop only when mailbox access matters; show the target address, delivery state, link or code instructions, expiry, resend and change-address actions, pending versus verified status, and safe recovery for expired or already-used messages.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A user must prove access to a mailbox before account activation, invitation acceptance, recovery eligibility, or sensitive notifications.
  • The service can send a time-limited link or code and maintain pending versus verified email state.
  • Users need recoverable resend, change-address, expired-link, and verified-return behavior.

Avoid when

  • The email is only needed for a low-risk receipt, newsletter, or optional contact route.
  • The user is still entering or correcting the address and mailbox access proof is not yet needed.
  • The task is password reset, multi-factor authentication, or phone confirmation.
  • The service cannot invalidate old links, limit resends, or protect confirmation artifacts.
  • The user can complete the task safely with review and change instead of a confirmation loop.

Problem it prevents

Services often need proof that a user controls an email address, but confirmation loops can block tasks unnecessarily, trap users with mistyped addresses, leak account state, or confuse email access proof with authentication.

Pattern anatomy

What a strong implementation has to make clear

User need

The service has already captured an email address and must decide whether syntactic validity is enough or mailbox access must be proven.

Pattern promise

Use a confirmation loop only when mailbox access matters; show the target address, delivery state, link or code instructions, expiry, resend and change-address actions, pending versus verified status, and safe recovery for expired or already-used messages.

Required state

Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.

Recovery path

Users are blocked because the confirmation email is delayed and there is no resend or pending route.

Access contract

Use a clear heading such as Confirm your email address and show the pending email address as text.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • After account creation, the page says We sent a confirmation link to maya@example.com, explains the link expires in 30 minutes, offers Resend email and Change email address, and returns to the draft after verification.
  • A code confirmation page accepts a pasted 6-digit code, shows the pending email address, and lets the user request a new code when the previous one expires.
  • A user mistypes the address, notices the pending address on the confirmation page, changes it, receives a fresh link, and continues from the same account-activation step.
  • A user opens an expired confirmation link, sees that the link no longer works, requests a new message, and returns to the verified account state after using it.
Weak implementation

Vague, hidden, hard to recover from

  • The page says Check your inbox but hides which email address was used and has no resend or change-address action.
  • A service blocks a low-risk receipt until the email is confirmed even though the user only needs a one-time copy.
  • A user never receives the activation email and cannot resend, change the address, or continue in a limited pending state.
  • A user clicks an old confirmation link and the page shows a raw token error with no explanation or recovery.
UI guidance
  • Render confirm email as a mailbox-access proof loop with the target address, sent-message status, link or code instructions, expiry, resend timing, change-address route, pending or verified state, and clear blocking or non-blocking behavior.
  • Keep email confirmation separate from email address entry, account creation, password reset, and two-factor authentication: it proves access to a specific mailbox, not just syntax, account persistence, password recovery, or an authentication factor.
UX guidance
  • Use confirm email when the service must know that the user can access the mailbox before activating an account, enabling recovery, sending sensitive notifications, accepting an invitation, or relying on the address for future access.
  • Help users recover from delayed, expired, already-used, or mistyped confirmation messages by showing what was sent, where it was sent, how long it lasts, how to resend, and how to change the address.
Implementation contract

What the implementation must handle

States

  • Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.
  • Blocking pending state where the task cannot continue until confirmation succeeds.
  • Non-blocking pending state where users can continue with limited access while confirmation remains outstanding.
  • Code entry state with paste support, autocomplete one-time-code when a short code is used, expiry hint, and submit control.

Interaction

  • The confirmation page states which email address is pending and why access to that mailbox is required.
  • Resend, change-address, and support actions preserve the originating task or account context.
  • Changing the address invalidates previous confirmation links or codes and sends a fresh confirmation to the new address.
  • Expired, already-used, malformed, or revoked artifacts never show raw token values and always offer a safe next step.

Accessibility

  • Use a clear heading such as Confirm your email address and show the pending email address as text.
  • Do not rely on email delivery alone; keep resend, change-address, support, and continue-later controls keyboard reachable.
  • Expose expiry, resend wait, and pending or verified status as text, not only color or icons.
  • For code confirmation, use a labelled input that supports paste and one-time-code autocomplete.

Review

  • Why does this flow need proof of mailbox access rather than only a valid email address?
  • Is the loop blocking, non-blocking, or limited-access, and is that visible to the user?
  • Can users see and change the email address before waiting for another message?
  • What happens when the email is delayed, expired, already used, opened on another device, or sent to a mistyped address?
Interactive lab

Inspect the states before you copy the pattern

Prove mailbox access without trapping the user

Send a confirmation link or code, show the pending address, switch between blocking and non-blocking loops, handle resend wait, change address, expired and used links, verify the mailbox, and compare hidden address, no resend, dead expired link, false verified, unnecessary block, stale link, and account reveal failures.

Confirm email
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.

Keyboard / Access

Initial focus lands on the confirmation heading or first useful pending-state action after the sent page loads.

Avoid Generating

Forcing email confirmation when the service only needs a low-risk contact or receipt address.
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • The service has already captured an email address and must decide whether syntactic validity is enough or mailbox access must be proven.
  • Confirmation may be needed for account activation, email change, invitation acceptance, recovery eligibility, sensitive notifications, legal notices, or high-impact communication.
  • The user may not receive the email immediately, may have entered the wrong address, may be using a shared mailbox, or may open a link after it expires.
  • Confirmation links and codes are short-lived artifacts that must not leak through logs, analytics, referrers, screenshots, or support transcripts.
  • Some services can continue in a pending or limited state while confirmation is outstanding; others must block until access is proven.

Selection Rules

  • Choose confirm email when the service must prove that the user can access the mailbox for account activation, recovery, sensitive notifications, invitation acceptance, or a verified contact route.
  • Use email address entry when the task is collecting, formatting, validating, warning about, or reviewing the address before mailbox access is proven.
  • Use account creation when the broader task is establishing a persistent account and confirm email is only one verification state inside that flow.
  • Use password reset when the email message is a recovery artifact for replacing a forgotten password rather than confirming a normal contact address.
  • Use two-factor authentication when an enrolled factor is needed for authentication or authorization; do not present email confirmation as equivalent to MFA.
  • Decide whether the loop is blocking, non-blocking, or limited-access before designing the confirmation page.
  • Show the exact email address that received the message and provide a direct way to change it when policy allows.
  • Explain link or code expiry, resend timing, spam or delivery delay guidance, and what will happen after confirmation.
  • Make confirmation links and codes time-limited, bound to the address and pending record, single-use where appropriate, and invalid after address change or successful confirmation.
  • Use neutral activation and resend copy where account enumeration matters.
  • After confirmation, update verified-email state, clear pending warnings, continue the blocked task, and notify or log according to security policy.

Required States

  • Pending sent state with target email address, purpose, next step, expiry, resend, and change-address action.
  • Blocking pending state where the task cannot continue until confirmation succeeds.
  • Non-blocking pending state where users can continue with limited access while confirmation remains outstanding.
  • Code entry state with paste support, autocomplete one-time-code when a short code is used, expiry hint, and submit control.
  • Resend-limited state with server-backed wait time.
  • Change-address state that invalidates previous confirmation artifacts.
  • Expired link or code state with request-new-message action.
  • Already-used or revoked link state with safe explanation and restart route.
  • Verified state that confirms mailbox access and returns to the original task.
  • Delivery trouble or support-needed state for inaccessible mailbox, delayed email, or repeated failed confirmations.

Interaction Contract

  • The confirmation page states which email address is pending and why access to that mailbox is required.
  • Resend, change-address, and support actions preserve the originating task or account context.
  • Changing the address invalidates previous confirmation links or codes and sends a fresh confirmation to the new address.
  • Expired, already-used, malformed, or revoked artifacts never show raw token values and always offer a safe next step.
  • Code entry supports paste, correction, mobile keyboards, and one-time-code autocomplete when the code is short-lived.
  • Confirmed state is stored separately from address syntax validity, deliverability, and account authentication.
  • The loop does not expose whether another account owns the address unless the user is already in a safer authenticated route.

Implementation Checklist

  • Define why email access is required, whether the loop blocks the task, the pending-state permissions, link or code expiry, resend limits, change-address behavior, and support route.
  • Design sent, pending, resend-limited, changed-address, expired, already-used, malformed, verified, and delivery-trouble states.
  • Bind confirmation artifacts to the email address, pending account or record, purpose, and expiry window; invalidate them after change, use, or account deletion.
  • Protect links, codes, address status, and token failure reasons from logs, analytics, referrers, screenshots, support tools, and URLs.
  • Use neutral copy for account activation and duplicate-account cases where account enumeration matters.
  • Test delayed delivery, wrong address, resend, multiple messages, expired link, already-used link, code paste, mobile email app handoff, browser Back, deep-link return, screen readers, and high zoom.

Common Generated-UI Mistakes

  • Forcing email confirmation when the service only needs a low-risk contact or receipt address.
  • Hiding the email address that received the confirmation message.
  • Providing no resend, change-address, expiry, or support route.
  • Treating email syntax validation as verified mailbox access.
  • Treating email confirmation as a second authentication factor for future sign-in.
  • Letting old confirmation links remain valid after the address changes or confirmation succeeds.
  • Showing raw token errors for expired or malformed links.
  • Revealing account existence through activation, resend, or duplicate-address messages.

Critique Questions

  • Why does this flow need proof of mailbox access rather than only a valid email address?
  • Is the loop blocking, non-blocking, or limited-access, and is that visible to the user?
  • Can users see and change the email address before waiting for another message?
  • What happens when the email is delayed, expired, already used, opened on another device, or sent to a mistyped address?
  • How are confirmation artifacts bound, expired, invalidated, and protected from leakage?
  • Does any activation or resend path reveal whether an account already exists?
Accessibility
  • Use a clear heading such as Confirm your email address and show the pending email address as text.
  • Do not rely on email delivery alone; keep resend, change-address, support, and continue-later controls keyboard reachable.
  • Expose expiry, resend wait, and pending or verified status as text, not only color or icons.
  • For code confirmation, use a labelled input that supports paste and one-time-code autocomplete.
  • Move focus to expired, already-used, and verified state headings or the first recovery action.
  • Avoid multi-field code inputs that trap focus unless paste, deletion, and screen-reader reading order are proven.
Keyboard Behavior
  • Initial focus lands on the confirmation heading or first useful pending-state action after the sent page loads.
  • Tab order reaches resend, change address, support, continue, and code entry controls in a predictable order.
  • Enter submits the visible code form only when a code field is present.
  • Expired or already-used link pages focus the heading or request-new-message action.
  • After changing the address, focus moves to the new sent-state heading and announces the updated target address.
  • After successful confirmation, focus lands on the resumed task, account activation result, or verified-email status.
Variants
  • Account activation link
  • Email confirmation code
  • Change-email confirmation
  • Invitation email confirmation
  • Sensitive notification verification
  • Blocking confirmation loop
  • Non-blocking confirmation loop
  • Limited-access pending email
  • Expired confirmation link
  • Already-used confirmation link
  • Resend confirmation email
  • Change pending email address

Verification

Last verified: