UX Patterns Guide
Back to compare picker

Email address entry vs Text input vs Inline validation vs Error summary

Use email address entry when the product needs a contactable email address with email-specific keyboard, autocomplete, validation, typo recovery, review, and optional access confirmation; use text input for ordinary short text, inline validation for local correction, and error summary for submitted-form recovery.

Email address entry live exampleText input live exampleInline validation live exampleError summary live example
Learn the decision

Match the interaction to the person's task

Use email address entry when the product needs a contactable email address with email-specific keyboard, autocomplete, validation, typo recovery, review, and optional access confirmation; use text input for ordinary short text, inline validation for local correction, and error summary for submitted-form recovery.

Email address entry

Use it when: The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.

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

Observe the result: A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.

Study the full pattern →

Text input

Use it when: The answer is short and user-authored.

Make this state clear: Empty untouched state with persistent label and optional hint.

Observe the result: A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.

Study the full pattern →

Inline validation

Use it when: A single field has a specific correctable problem.

Make this state clear: Invalid field with preserved user value and adjacent correction text.

Observe the result: Validation appears after blur or submit when it helps correction.

Study the full pattern →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Practice the judgment: Imagine this situation: A regex rejects a valid long or uncommon domain address that the service could have delivered to. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Email address entryText inputInline validationError summary
UI or UX UI + UX - Contactable email address capture fieldUI + UX - Single-line freeform data-entry controlUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
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.Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
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.Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.Help the person reach a clear task outcome.Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI 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.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com.The only instruction is placeholder text that disappears when the user starts typing.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.
Good UX 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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.Showing errors before users type.Only showing errors below the fold.
Best fit The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.The answer is short and user-authored.A single field has a specific correctable problem.Form submission can produce one or more errors.
Avoid when The flow needs a phone number, postal address, payment account, password, or one-time code instead.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.The main recovery task is finding several errors across a submitted page.The message is a system failure, permission problem, or outage rather than a validation issue.
Required state Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.Empty untouched state with persistent label and optional hint.Invalid field with preserved user value and adjacent correction text.Failed-submit state with summary visible near the form heading.
Accessibility burden Use a visible label that names the value as an email address and a hint that explains why it is requested.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.
Common misuse Blocking paste or browser autofill.Using placeholder text as the only label or instruction.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.

Email address entry

UI or UX
UI + UX - Contactable email address capture field
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.
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.
Good UI
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.
Bad UI
A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com.
Good UX
A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.
Bad UX
A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign.
Best fit
The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.
Avoid when
The flow needs a phone number, postal address, payment account, password, or one-time code instead.
Required state
Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
Accessibility burden
Use a visible label that names the value as an email address and a hint that explains why it is requested.
Common misuse
Blocking paste or browser autofill.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help the person reach a clear task outcome.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Error message appears far from the field it describes.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Invalid field with preserved user value and adjacent correction text.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.
Decision rules
  • Prefer email address entry when the value will be used to send receipts, notifications, account recovery links, sign-in identifiers, invitations, or verification messages.
  • Prefer text input when the value is an ordinary label, username, reference, organization name, or note that should not be parsed, autofilled, or validated as an email address.
  • Prefer inline validation inside email address entry for missing value, malformed address, repeated whitespace, unsupported multiple-address entry, provider typo warning, or unreachable confirmation state tied to this one field.
  • Prefer error summary when a submitted account, checkout, or contact form has several errors and users need a top-of-form list that links back to the email field.
  • Use type email, autocomplete email, spellcheck false, visible label, and enough width for users to review most addresses, while still validating on the server.
  • Allow paste and browser autofill; do not split the local part and domain into separate fields or block plus tags, subdomains, long addresses, or uncommon domains merely because they look unfamiliar.
  • Warn on likely provider typos such as homtail.com or gmial.com, but let users keep the value because uncommon domains can be genuine.
  • Confirm the entered address back to users on a review page or local summary when email is used for receipts, notifications, recovery, or account access.
  • Use an email confirmation loop only when access to that mailbox is essential, such as account activation or password reset; avoid it for low-consequence contact fields.
  • Do not ask users to repeat the email address unless research for this service shows it reduces errors; review and change usually create less friction.
Inspect live examples
Email address entryText inputInline validationError summary
Failure modes
  • A form uses a plain text input and mobile users do not get the email keyboard or email autofill.
  • The field blocks paste or plus-addressing, so users cannot use their real address or password-manager-stored identity.
  • A regex rejects a valid long or uncommon domain address that the service could have delivered to.
  • The form silently corrects gmial.com to gmail.com and sends sensitive mail to the wrong address.
  • A product requires email confirmation for a low-risk receipt and causes avoidable abandonment.
  • A top-of-page error says invalid value without linking back to the email field or preserving the typed address.

Saved items