UX Patterns Guide
Back to compare picker

Character count vs Textarea vs Text input vs Inline validation

Prefer character count when a real maximum character or word limit affects whether the value can be accepted and users benefit from seeing remaining capacity while writing.

Character count live exampleTextarea live exampleText input live exampleInline validation live example

Decision dimensions

Dimension Character countTextareaText inputInline validation
UI or UX UI + UX - Bounded text-entry length feedbackUI + UX - Multi-line freeform writing fieldUI + UX - Single-line freeform data-entry controlUI + UX - Field-level validation feedback
UI guidance Place count feedback next to the limited input or textarea, associate it with the field description, and show the maximum or remaining amount in the same unit the service validates.Render a persistent label, enough visible rows for the expected answer, optional hint, readable multiline text, visible focus state, and nearby error or count text associated with the textarea.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 character count only when a real character or word limit affects acceptance and users can adjust their answer before submission.Use textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines.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 An appeal summary textarea says users can enter up to 120 characters, shows no urgent count while plenty of space remains, then changes to 18 characters remaining near the threshold.A more-detail field has a visible question, sensitive-data hint, five visible rows, wrapping text, remaining-character count, and an error directly above the textarea when needed.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 long unrestricted comment box shows a decorative 5000-character counter that makes users think the answer should be shorter.A paragraph question is squeezed into a single-line input that hides most of the answer.The only instruction is placeholder text that disappears when the user starts typing.Only a red border with no message.
Good UX A user pastes a long summary, sees that it is 23 characters over the limit, trims it in place, and submits without losing the original draft.A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved.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 composes a paragraph and the field silently truncates the last sentence at the maximum length.A user writes a long explanation, hits submit, and the product clears the entire draft after a length error.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 A legal, editorial, messaging, moderation, or display constraint imposes a clear maximum length.Users need to write sentences, paragraphs, comments, explanations, notes, or descriptions.The answer is short and user-authored.A single field has a specific correctable problem.
Avoid when The field has no meaningful maximum length.The answer is a short one-line value.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 visible label, hint, and static maximum message.Empty untouched state with visible label and optional hint.Empty untouched state with persistent label and optional hint.Neutral field with label, hint, and no error.
Accessibility burden Associate the count message with the field so users hear the limit and current status with the control.Associate the textarea with a visible label that states the writing prompt.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 Adding a counter to an unrestricted writing field because it looks informative.Using a single-line input for paragraph answers.Using placeholder text as the only label or instruction.Showing field errors before users have interacted with the control.

Character count

UI or UX
UI + UX - Bounded text-entry length feedback
UI guidance
Place count feedback next to the limited input or textarea, associate it with the field description, and show the maximum or remaining amount in the same unit the service validates.
UX guidance
Use character count only when a real character or word limit affects acceptance and users can adjust their answer before submission.
Good UI
An appeal summary textarea says users can enter up to 120 characters, shows no urgent count while plenty of space remains, then changes to 18 characters remaining near the threshold.
Bad UI
A long unrestricted comment box shows a decorative 5000-character counter that makes users think the answer should be shorter.
Good UX
A user pastes a long summary, sees that it is 23 characters over the limit, trims it in place, and submits without losing the original draft.
Bad UX
A user composes a paragraph and the field silently truncates the last sentence at the maximum length.
Best fit
A legal, editorial, messaging, moderation, or display constraint imposes a clear maximum length.
Avoid when
The field has no meaningful maximum length.
Required state
Empty state with visible label, hint, and static maximum message.
Accessibility burden
Associate the count message with the field so users hear the limit and current status with the control.
Common misuse
Adding a counter to an unrestricted writing field because it looks informative.

Textarea

UI or UX
UI + UX - Multi-line freeform writing field
UI guidance
Render a persistent label, enough visible rows for the expected answer, optional hint, readable multiline text, visible focus state, and nearby error or count text associated with the textarea.
UX guidance
Use textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines.
Good UI
A more-detail field has a visible question, sensitive-data hint, five visible rows, wrapping text, remaining-character count, and an error directly above the textarea when needed.
Bad UI
A paragraph question is squeezed into a single-line input that hides most of the answer.
Good UX
A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved.
Bad UX
A user writes a long explanation, hits submit, and the product clears the entire draft after a length error.
Best fit
Users need to write sentences, paragraphs, comments, explanations, notes, or descriptions.
Avoid when
The answer is a short one-line value.
Required state
Empty untouched state with visible label and optional hint.
Accessibility burden
Associate the textarea with a visible label that states the writing prompt.
Common misuse
Using a single-line input for paragraph answers.

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 character count when a real maximum character or word limit affects whether the value can be accepted and users benefit from seeing remaining capacity while writing.
  • Prefer textarea without a counter when the task is long-form writing but the product does not enforce a meaningful maximum or the limit is far beyond normal answers.
  • Prefer text input when the answer is short, single-line, and its length is obvious from the data type, such as a postcode, phone number, or short reference.
  • Prefer inline validation when the main need is a specific correction after blur or submit, such as required, too short, disallowed characters, or format mismatch.
  • Do not use character count to paper over backend limits users frequently hit; raise the limit or redesign the data model before adding count pressure.
  • Do not announce every keystroke as a status update; use calm count text, thresholded warnings, or delayed live messages so assistive technology is not overwhelmed.
  • Use word count instead of character count only when policy, moderation, legal copy, or editorial constraints are expressed in words rather than characters.
  • If JavaScript fails, keep a static maximum-length message visible so users still know the limit before submitting.
  • When a user exceeds the limit, preserve the full draft, show the amount over the limit, and provide a trim or edit path instead of truncating silently.
  • If the count is only decorative or likely to make users spend extra time shortening useful content, remove it and use hint text or validation only when needed.
Inspect live examples
Character countTextareaText inputInline validation
Failure modes
  • A form enforces a hard hidden limit and only tells users after they submit a long answer.
  • The counter appears on an unrestricted comment field and makes users shorten useful context for no product reason.
  • A counter updates through an aggressive live region on every keystroke and interrupts screen reader users.
  • A backend limit is too low, but the interface shifts the burden to users instead of fixing the service constraint.
  • The component counts characters visually while server validation counts bytes, words, or normalized characters.
  • The product silently truncates pasted text instead of preserving the draft and explaining how much must be removed.