Input prefix/suffix vs Input mask vs Text input vs Inline validation

Prefer input prefix/suffix when the affix is a stable, commonly understood unit, currency symbol, percentage sign, domain, or icon that clarifies what the user should enter.

Input prefix/suffix live example Input mask live example Text input live example Inline validation live example

Decision dimensions

Dimension	Input prefix/suffix	Input mask	Text input	Inline validation
UI or UX	UI + UX - Text input with constant visual affix	UI + UX - Fixed-format text entry control	UI + UX - Single-line freeform data-entry control	UI + UX - Field-level validation feedback
UI guidance	Render the prefix before the input or suffix after the input as a non-editable visual affix, with a persistent label or hint that names the unit or symbol in text.	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 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.
UX guidance	Use a prefix or suffix to reduce ambiguity when users must enter only the value and the unit, currency, percentage, or domain is fixed.	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.	Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.	Help users correct a specific field without losing or re-entering the value they already typed.
Good UI	A Cost, in dollars field shows a dollar prefix outside the input, uses numeric input, and stores only the numeric amount.	A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 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.
Bad UI	A field labeled Amount shows a hidden dollar prefix but the label never says dollars.	A phone field hard-codes a domestic mask and rejects valid international numbers.	The only instruction is placeholder text that disappears when the user starts typing.	Only a red border with no message.
Good UX	A user types $1,250 into a field with a dollar prefix and the form normalizes it to 1250 with a clear status message.	A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.	A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.	Validation appears after blur or submit when it helps correction.
Bad UX	A user types lbs after a weight value because they missed the suffix, then gets an error instead of normalization.	A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.	Validation fires on the first focus event and blocks typing before the user has had a chance to answer.	Showing errors before users type.
Best fit	The value has a fixed currency, unit, percentage, domain, or commonly understood icon.	The value has a stable character pattern and users benefit from live grouping.	The answer is short and user-authored.	A single field has a specific correctable problem.
Avoid when	The answer is open-ended or may not use the shown unit.	Valid values have many lengths, regions, scripts, or exception formats.	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.
Required state	Empty state with descriptive label and visible prefix or suffix.	Empty untouched state with label and visible format example.	Empty untouched state with persistent label and optional hint.	Neutral field with label, hint, and no error.
Accessibility burden	Do not rely on the visual affix alone; include the unit or symbol meaning in the label or hint.	Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.	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.
Common misuse	Relying on a visually hidden or decorative affix as the only way users know the unit.	Using a mask because a format exists even though many valid values do not fit it.	Using placeholder text as the only label or instruction.	Showing field errors before users have interacted with the control.

Input prefix/suffix

UI or UX: UI + UX - Text input with constant visual affix
UI guidance: Render the prefix before the input or suffix after the input as a non-editable visual affix, with a persistent label or hint that names the unit or symbol in text.
UX guidance: Use a prefix or suffix to reduce ambiguity when users must enter only the value and the unit, currency, percentage, or domain is fixed.
Good UI: A Cost, in dollars field shows a dollar prefix outside the input, uses numeric input, and stores only the numeric amount.
Bad UI: A field labeled Amount shows a hidden dollar prefix but the label never says dollars.
Good UX: A user types $1,250 into a field with a dollar prefix and the form normalizes it to 1250 with a clear status message.
Bad UX: A user types lbs after a weight value because they missed the suffix, then gets an error instead of normalization.
Best fit: The value has a fixed currency, unit, percentage, domain, or commonly understood icon.
Avoid when: The answer is open-ended or may not use the shown unit.
Required state: Empty state with descriptive label and visible prefix or suffix.
Accessibility burden: Do not rely on the visual affix alone; include the unit or symbol meaning in the label or hint.
Common misuse: Relying on a visually hidden or decorative affix as the only way users know the unit.

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.

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.

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.

Decision rules

Prefer input prefix/suffix when the affix is a stable, commonly understood unit, currency symbol, percentage sign, domain, or icon that clarifies what the user should enter.
Prefer input mask when the typed value itself has fixed character groups, literals, or slots that should be inserted or formatted while users type.
Prefer text input when the answer is short and freeform, or when adding an affix would imply a narrower value than users may legitimately provide.
Prefer inline validation when users can enter the value normally and the main need is a field-adjacent correction after blur or submit.
The label or hint must name the unit or meaning because prefixes and suffixes may be visually adjacent but hidden from assistive technologies.
Do not use an affix when a full word or explanatory sentence is needed; add hint text or redesign the question instead.
Do not reject values just because the user typed the same currency symbol or unit shown in the affix; normalize the duplicate or explain the accepted value.
Keep the affix outside the editable text value so copy, paste, validation, and backend storage have a predictable canonical value.
Use input width, inputmode, and validation that match the value without the affix, such as numeric entry for dollars, pounds, percentages, or dimensions.
If the unit can change, use a separate select or segmented control rather than a static suffix that silently changes meaning.

Inspect live examples

Input prefix/suffix Input mask Text input Inline validation

Failure modes

The visible suffix says lbs but the label only says Weight, so screen reader users miss the unit.
A dollar prefix is used for an open-ended resolution field where users might answer with a refund, repair, or non-monetary outcome.
The form rejects $1200 even though the UI displayed a dollar prefix and many users naturally typed it.
A suffix is included in the stored value for one field but stripped for another, causing inconsistent backend data.
A long explanatory phrase is forced into a suffix and wraps or overlaps the input.
A static suffix remains visible after the unit or locale changes elsewhere in the form.