UX Patterns Guide
Back to compare picker

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

Use phone number entry when the product needs a callable or textable contact route with telephone keyboard, purpose text, contact-choice recovery, familiar-format tolerance, review, and optional access confirmation; use text input for ordinary short text, input mask only for narrow fixed formats, inline validation for local correction, and error summary for failed submitted forms.

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

Match the interaction to the person's task

Use phone number entry when the product needs a callable or textable contact route with telephone keyboard, purpose text, contact-choice recovery, familiar-format tolerance, review, and optional access confirmation; use text input for ordinary short text, input mask only for narrow fixed formats, inline validation for local correction, and error summary for failed submitted forms.

Phone number entry

Use it when: The product must capture a phone number for calls, texts, support callbacks, appointment changes, recovery, delivery coordination, verification, or contact records.

Make this state clear: Initial state with label naming the needed number type, purpose hint, type tel, autocomplete tel, and contact-choice wording.

Observe the result: A user pastes 07700 900 982, sees it preserved, reviews that calls may go to that number, and can choose email instead.

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 →

Input mask

Use it when: The value has a stable character pattern and users benefit from live grouping.

Make this state clear: Empty untouched state with label and visible format example.

Observe the result: A user submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.

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 form stores the phone as a number and strips a leading zero or plus sign. 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 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.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.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 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 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 The phone number is stored as a numeric value and loses a leading zero.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.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.
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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.A user submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.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 an extension for a desk phone, but validation strips it and the organization later calls the wrong line.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.The message is a system failure, permission problem, or outage rather than a validation issue.
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.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 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.Connect hint, format example, canonical-value note, and error text to the input with descriptive relationships where supported.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.Rejecting pasted values that include spaces, dashes, parentheses, or lowercase characters.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.

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
The phone number is stored as a numeric value and loses a leading zero.
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 enters an extension for a desk phone, but validation strips it and the organization later calls the wrong line.
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
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.

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 submits ABCD 123 and receives a precise error that the six-digit serial group and check digit are incomplete.
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
Connect hint, format example, canonical-value note, and error text to the input with descriptive relationships where supported.
Common misuse
Rejecting pasted values that include spaces, dashes, parentheses, or lowercase characters.

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 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.

Saved items