UX Patterns Guide
Back to compare picker

Phone number entry vs Text input vs Input mask vs Inline validation vs Error summary

Prefer phone number entry when the value will be used to call, text, identify, recover, confirm, or route a user through a telephone network.

Phone number entry live exampleText input live exampleInput mask live exampleInline validation live exampleError summary live example

Decision dimensions

Dimension Phone number entryText inputInput maskInline validationError summary
UI or UX UI + UX - Callable telephone contact capture fieldUI + UX - Single-line freeform data-entry controlUI + UX - Fixed-format text entry controlUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
UI guidance Render phone entry as a labelled single-line field with number type in the label or hint, purpose and contact-timing text, type tel, autocomplete tel, field-specific errors, and review of both the user's displayed number and any dialable backend value.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.Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.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 phone number entry when the product genuinely needs to call, text, verify, route, or recover contact with a user through a phone number.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.Help users correct a specific field without losing or re-entering the value they already typed.Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI An appointment service asks for UK mobile or international phone number, says it will call only if the appointment changes, uses type tel and autocomplete tel, and shows the number for review before saving.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.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 form stores phone as a number, removes the leading zero from 07700 900 982, and offers no way to correct the stored value.The only instruction is placeholder text that disappears when the user starts typing.A phone field hard-codes a domestic mask and rejects valid international numbers.Only a red border with no message.Red banner saying fix errors with no links.
Good UX A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead.A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.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 with an international number cannot type the plus sign because the field uses type number.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.Showing errors before users type.Only showing errors below the fold.
Best fit The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records.The answer is short and user-authored.The value has a stable character pattern and users benefit from live grouping.A single field has a specific correctable problem.Form submission can produce one or more errors.
Avoid when The product only needs a name, label, username, reference, or other short text.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.Valid values have many lengths, regions, scripts, or exception formats.The main recovery task is finding several errors across a submitted page.A single local field issue can be corrected before submit without page-level orientation.
Required state Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.Empty untouched state with persistent label and optional hint.Empty untouched state with label and visible format example.Neutral field with label, hint, and no error.Neutral form before submit with no summary.
Accessibility burden Use a visible label and hint that state the number type, purpose, and any contact timing.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.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 Using type number and losing leading zeros or plus signs.Using placeholder text as the only label or instruction.Using a mask because a format exists even though many valid values do not fit it.Showing field errors before users have interacted with the control.Showing a red banner or toast with no links to the invalid answers.

Phone number entry

UI or UX
UI + UX - Callable telephone contact capture field
UI guidance
Render phone entry as a labelled single-line field with number type in the label or hint, purpose and contact-timing text, type tel, autocomplete tel, field-specific errors, and review of both the user's displayed number and any dialable backend value.
UX guidance
Use phone number entry when the product genuinely needs to call, text, verify, route, or recover contact with a user through a phone number.
Good UI
An appointment service asks for UK mobile or international phone number, says it will call only if the appointment changes, uses type tel and autocomplete tel, and shows the number for review before saving.
Bad UI
A form stores phone as a number, removes the leading zero from 07700 900 982, and offers no way to correct the stored value.
Good UX
A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead.
Bad UX
A user with an international number cannot type the plus sign because the field uses type number.
Best fit
The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records.
Avoid when
The product only needs a name, label, username, reference, or other short text.
Required state
Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.
Accessibility burden
Use a visible label and hint that state the number type, purpose, and any contact timing.
Common misuse
Using type number and losing leading zeros or plus signs.

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
Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
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 types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
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.

Input mask

UI or UX
UI + UX - Fixed-format text entry control
UI guidance
Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.
UX guidance
Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.
Good UI
A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.
Bad UI
A phone field hard-codes a domestic mask and rejects valid international numbers.
Good UX
A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.
Bad UX
A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.
Best fit
The value has a stable character pattern and users benefit from live grouping.
Avoid when
Valid values have many lengths, regions, scripts, or exception formats.
Required state
Empty untouched state with label and visible format example.
Accessibility burden
Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.
Common misuse
Using a mask because a format exists even though many valid values do not fit it.

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 users correct a specific field without losing or re-entering the value they already typed.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Only a red border with no message.
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
Neutral field with label, hint, and no error.
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
Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Red banner saying fix errors with no links.
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
A single local field issue can be corrected before submit without page-level orientation.
Required state
Neutral form before submit with no summary.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Showing a red banner or toast with no links to the invalid answers.
Decision rules
  • Prefer phone number entry when the value will be used to call, text, identify, recover, confirm, or route a user through a telephone network.
  • Prefer text input when the value is a name, label, username, reference, or contact preference that must not be parsed as a telephone number.
  • Prefer input mask only when the service accepts a narrow domestic phone-number format with no international numbers, extensions, short codes, or assistive exceptions; otherwise use tolerant phone number entry with validation after entry.
  • Prefer inline validation inside phone number entry for missing number, too few digits, unsupported country code, non-SMS-capable number in an SMS flow, extension handling, or ambiguous contact method.
  • Prefer error summary when a submitted appointment, account, or contact form has several errors and users need a top-of-form list that links back to the phone field.
  • Use type tel and autocomplete tel for a complete phone number; use tel-country-code, tel-national, tel-area-code, tel-local, or tel-extension only when the product deliberately splits the number into parts.
  • Do not use type number because phone numbers are identifiers, not arithmetic values; leading zeros, plus signs, spaces, parentheses, and extensions can be meaningful to users.
  • Tell users whether you need UK, international, mobile, landline, SMS-capable, or extension-bearing numbers, and explain when the organization may call or text.
  • Allow users to enter familiar formatting and paste from contacts; trim harmless whitespace but avoid silently rewriting the display value or forcing an unfamiliar international format into the field.
  • Offer another contact route when users do not have a phone, cannot use one, share one, cannot receive SMS, or need relay, email, post, or support contact.
  • Review the exact phone number and contact method before consequential use, and separately store the dialable canonical value used by telephony systems.
  • Use phone confirmation only when phone access must be proven; do not force SMS verification for low-risk contact fields or for landline-only users.
Inspect live examples
Phone number entryText inputInput maskInline validationError summary
Failure modes
  • A form stores the phone as a number and strips a leading zero or plus sign.
  • A domestic mask rejects international numbers, extensions, or pasted numbers with spaces and parentheses.
  • A service asks for a phone number without explaining why it is needed or when the user might be contacted.
  • A sign-in flow forces SMS verification and blocks users with landlines, shared phones, inaccessible devices, or relay needs.
  • A reformatter changes the displayed number so users no longer recognize what they entered.
  • A top-of-page error says invalid value without linking back to the phone field or preserving the typed number.