UX Patterns Guide
UI + UX Input And Data Entry standard

Email address entry

Use an email-specific field with clear purpose, paste and autofill support, email keyboard and autocomplete, tolerant validation, provider typo warnings, preserved values, review and change, and confirmation loops only when mailbox access is essential.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.
  • Users may need to choose among multiple personal, work, shared, or recovery addresses.
  • The service can preserve, review, validate, and where necessary confirm the address before relying on it.
  • The address needs email-specific keyboard, autocomplete, and spelling behavior.

Avoid when

  • The value is a username, label, reference, organization name, or other short text that may not be an email address.
  • The flow needs a phone number, postal address, payment account, password, or one-time code instead.
  • The product cannot safely send email, handle bounces, change an incorrect address, or explain confirmation failures.
  • Users should choose from known contacts or account records rather than type a new address.
  • The task requires multiple recipients but the product has not designed recipient chips, errors, and review for multiple addresses.

Problem it prevents

Email addresses look simple but are easy to mistype, may be long or uncommon, often come from password managers or copy and paste, and can affect account recovery, receipts, notifications, and access confirmation.

Pattern anatomy

What a strong implementation has to make clear

User need

The service needs to send receipts, status updates, invitations, alerts, reset links, verification messages, or account notifications.

Pattern promise

Use an email-specific field with clear purpose, paste and autofill support, email keyboard and autocomplete, tolerant validation, provider typo warnings, preserved values, review and change, and confirmation loops only when mailbox access is essential.

Required state

Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.

Recovery path

The wrong email receives a receipt, recovery link, or private notification because the user could not review it.

Access contract

Use a visible label that names the value as an email address and a hint that explains why it is requested.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A receipt form asks for Email address, says We will only use this to send your receipt, uses type email and autocomplete email, and shows a review row before submit.
  • An account recovery form accepts alex+tax@example.co.uk, warns if the domain looks like gmial.com, and lets the user either change it or keep it.
  • A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.
  • A user types ada@gmial.com, receives a warning that they may have meant gmail.com, and can either fix it or keep the original address.
Weak implementation

Vague, hidden, hard to recover from

  • A form uses a plain text field named Contact and later rejects it as not email-shaped after submit.
  • A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com.
  • A user with a long work address cannot see enough of it to spot a typo before the service sends a reset link.
  • A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign.
UI guidance
  • Render email entry as a labelled single-line field with purpose text, type email, autocomplete email, spellcheck disabled, enough visible width for review, field-specific errors, and optional typo warning and review states.
  • Keep the full address editable and visible enough to inspect; do not split the address into local-part and domain fields or replace the user's value with an unconfirmed correction.
UX guidance
  • Use email address entry when the product must contact the user, identify an account, send a receipt, invite someone, or confirm access to a mailbox.
  • Help users provide a deliverable address by allowing paste and autofill, preserving valid address forms, explaining format problems, warning about likely provider typos, and confirming back the address before consequential use.
Implementation contract

What the implementation must handle

States

  • Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
  • Focused state with email keyboard and normal typing, paste, selection, undo, and autofill behavior.
  • Pasted address state preserving plus tags, case where relevant for display, subdomains, and long domains.
  • Missing required email state with field-specific error text.

Interaction

  • Users can type, paste, autofill, edit, select, undo, and correct the email value through native input behavior.
  • Submitting an empty or malformed address keeps the typed value and puts the correction next to the field or in a linked summary.
  • Provider typo warnings are advisory and never overwrite the user's value without confirmation.
  • Review states show the exact address that will receive messages and provide a direct change path.

Accessibility

  • Use a visible label that names the value as an email address and a hint that explains why it is requested.
  • Use autocomplete email to identify the input purpose for autofill and assistive technologies.
  • Connect hint, warning, and error text to the field with descriptive relationships.
  • Do not rely on placeholder text or browser validation messages as the only instruction.

Review

  • What will the service send to this email address and how should users choose which mailbox to provide?
  • Does the field use type email, autocomplete email, spellcheck false, and enough visible width?
  • Can users paste or autofill plus-tagged, long, or uncommon-domain addresses without rejection?
  • What happens when a user enters a likely provider typo such as gmial.com?
Interactive lab

Inspect the states before you copy the pattern

Capture a contactable email address

Paste a plus-addressed email, trigger malformed and provider-typo states, keep or fix the warning, review the exact address, and inspect when confirmation is needed.

Email address entry
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

Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.

Keyboard / Access

Tab order follows the email field, typo warning actions when present, review change action, and submit or confirmation controls.

Avoid Generating

Using a plain text input without email autocomplete or email keyboard support.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Email addresses pattern

GOV.UK Design System - checked

GOV.UK supports email-purpose text, type email, autocomplete email, spellcheck false, paste support, 254-character capacity, visible width, typo warnings, review, and confirmation loops only when access is essential.

ONS Design System Email addresses pattern

Office for National Statistics - checked

ONS supports email purpose descriptions, type email, autocomplete email, paste support, check-answers review, and confirmation only where research supports it.

MDN input type email

MDN Web Docs - checked

MDN supports email input semantics, automatic email-format validation, supported attributes, and multiple-address handling.

HTML Standard email input state

WHATWG - checked

WHATWG supports the email input state, valid email grammar, type mismatch validation, and multiple-address handling.

Full agent/debug reference

Problem Context

  • The service needs to send receipts, status updates, invitations, alerts, reset links, verification messages, or account notifications.
  • Users may have multiple addresses and need to know whether to give work, personal, recovery, shared, or temporary email.
  • Addresses may include plus tags, subdomains, long domains, uncommon top-level domains, uppercase letters, dots, hyphens, and pasted whitespace.
  • A syntactically valid email address does not prove that the user owns or can access the mailbox.
  • Wrong addresses can leak information, block recovery, prevent receipts, or send a message to another person.

Selection Rules

  • Choose email address entry when the field value must be an email address used for contact, identity, invitation, recovery, notification, or receipt delivery.
  • Use type email, autocomplete email, spellcheck false, and a visible label that says Email address or names the mailbox purpose.
  • Explain why the address is needed unless the purpose is already obvious in a sign-in context.
  • Allow paste, browser autofill, plus addressing, subdomains, long addresses, and uncommon domains.
  • Size the field so most users can inspect at least the main part of the address, and support up to 254 characters.
  • Validate empty and malformed values after blur or submit, preserve the entered value, and say how to fix it.
  • Trim accidental leading and trailing spaces, but do not silently rewrite the local part, domain, or provider.
  • Warn on likely provider typos and offer a suggested domain, but let users keep the original address.
  • Use the multiple attribute only when the task truly accepts multiple comma-separated addresses; otherwise reject multiple addresses clearly.
  • Show the captured address on review or confirmation before sending consequential email.
  • Use an email confirmation loop only when the service must know that the user can access the mailbox.
  • Do not require repeated email entry, block paste, or force confirmation loops unless research and risk justify the extra friction.

Required States

  • Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
  • Focused state with email keyboard and normal typing, paste, selection, undo, and autofill behavior.
  • Pasted address state preserving plus tags, case where relevant for display, subdomains, and long domains.
  • Missing required email state with field-specific error text.
  • Malformed email state with an example such as name@example.com.
  • Likely provider typo warning state with change, keep, or suggested-domain action.
  • Multiple addresses rejected state when only one address is allowed.
  • Long address state where enough of the value can be inspected and no silent truncation occurs.
  • Reviewed address state with change action before receipt, notification, recovery, or invitation is sent.
  • Email confirmation pending state when access to the mailbox must be proven.
  • Delivered or verified state that records contactability separately from syntactic validity.

Interaction Contract

  • Users can type, paste, autofill, edit, select, undo, and correct the email value through native input behavior.
  • Submitting an empty or malformed address keeps the typed value and puts the correction next to the field or in a linked summary.
  • Provider typo warnings are advisory and never overwrite the user's value without confirmation.
  • Review states show the exact address that will receive messages and provide a direct change path.
  • Confirmation loops explain what was sent, where it was sent, how long the code or link lasts, and how to change the address.
  • The backend treats syntax validity, deliverability, ownership, and verified access as separate states.

Implementation Checklist

  • Use a native input with type email, autocomplete email, spellcheck false, a stable label, purpose hint, and aria-describedby for hint, warning, and error text.
  • Support paste, autofill, mobile email keyboard, long values, plus tags, subdomains, uncommon domains, and copied addresses with leading or trailing spaces.
  • Validate required and email-format errors on the client and server, and avoid brittle regular expressions that reject real addresses.
  • Add provider typo detection for common domains only as a warning with keep and change paths.
  • Use a review page, summary row, or confirmation panel before sending important email.
  • Use email access confirmation only for account activation, password reset, sensitive notifications, or flows where mailbox access is required.
  • Test password managers, browser autofill, paste, mobile keyboard, screen readers, zoom, long addresses, plus tags, multiple-address attempts, provider typos, bounced email, and confirmation timeout.

Common Generated-UI Mistakes

  • Using a plain text input without email autocomplete or email keyboard support.
  • Blocking paste or browser autofill.
  • Rejecting plus-addressed, long, subdomain, or uncommon-domain addresses with a narrow regex.
  • Silently correcting a provider typo and sending mail to the changed address.
  • Asking users to repeat the email address without evidence that it helps.
  • Forcing an email confirmation loop for low-risk contact or receipt fields.
  • Hiding the entered address so users cannot review it before a reset link or receipt is sent.
  • Treating syntactic validity as proof that the mailbox exists or belongs to the user.

Critique Questions

  • What will the service send to this email address and how should users choose which mailbox to provide?
  • Does the field use type email, autocomplete email, spellcheck false, and enough visible width?
  • Can users paste or autofill plus-tagged, long, or uncommon-domain addresses without rejection?
  • What happens when a user enters a likely provider typo such as gmial.com?
  • Does the flow need mailbox access confirmation, or is review and change enough?
  • How are format validity, deliverability, bounced messages, and verified access represented separately?
Accessibility
  • Use a visible label that names the value as an email address and a hint that explains why it is requested.
  • Use autocomplete email to identify the input purpose for autofill and assistive technologies.
  • Connect hint, warning, and error text to the field with descriptive relationships.
  • Do not rely on placeholder text or browser validation messages as the only instruction.
  • Present typo warnings, errors, and confirmation states in text, not only color or icons.
  • Keep the address review and change controls reachable by keyboard and screen reader.
  • Make confirmation-loop resend, change-address, and timeout recovery paths accessible.
Keyboard Behavior
  • Tab order follows the email field, typo warning actions when present, review change action, and submit or confirmation controls.
  • Typing, paste, selection, deletion, undo, redo, and autofill use native input behavior.
  • Enter submits the surrounding form only when the form contract is clear.
  • Submitting an invalid address moves focus to the error summary or email field without clearing the value.
  • Warning actions such as Use suggested domain and Keep original are reachable by keyboard.
  • Confirmation code or link recovery does not trap focus away from changing the email address.
Variants
  • Contact email address
  • Sign-in email address
  • Receipt email
  • Recovery email
  • Invitation email
  • Email with provider typo warning
  • Email review before submit
  • Email confirmation pending
  • Multiple email address field
  • Verified email state

Verification

Last verified: