UX Patterns Guide
Back to compare picker

Textarea vs Text input vs Inline validation vs Error summary

Use textarea for multi-line freeform writing, text input for short one-line answers, inline validation for field-level feedback, and error summary for page-level navigation to errors.

Textarea live exampleText input live exampleInline validation live exampleError summary live example
Learn the decision

Match the interaction to the person's task

Use textarea for multi-line freeform writing, text input for short one-line answers, inline validation for field-level feedback, and error summary for page-level navigation to errors.

Textarea

Use it when: Users need to write sentences, paragraphs, comments, explanations, notes, or descriptions.

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

Observe the result: A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved.

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 paragraph answer is forced into a one-line text input, hiding most of the response. 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 TextareaText inputInline validationError summary
UI or UX UI + UX - Multi-line freeform writing fieldUI + UX - Single-line freeform data-entry controlUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
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.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 textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines.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 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.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI 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.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.
Good UX A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved.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 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.Only showing errors below the fold.
Best fit 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.Form submission can produce one or more errors.
Avoid when 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.The message is a system failure, permission problem, or outage rather than a validation issue.
Required state Empty untouched state with visible label and optional hint.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 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.Use a heading and alert behavior that makes the summary discoverable.
Common misuse 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.Replacing field-level messages with only a top-level summary.

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
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 textarea when the expected answer needs sentences, paragraphs, line breaks, or visible review of longer freeform text.
  • Prefer text input when the expected answer is a short single-line value such as a name, title, code, or one-line reference.
  • Use inline validation with textarea when feedback belongs directly next to the long-answer field, such as required, too short, too long, or disallowed-character errors.
  • Use an error summary when one or more textarea or form errors need a page-level list that moves users back to the exact field.
  • Add a character count only when a limit is real and useful; do not show a counter merely to decorate an unrestricted long-answer field.
  • Do not hide paragraph entry in a one-line input; users need wrapping, scrolling, line-break behavior, and enough visible rows to review what they wrote.
  • Do not replace textarea with a rich text editor unless formatting, links, headings, or structured content are genuinely part of the task.
  • Set rows and visible height based on expected answer length, not on a generic form layout.
  • When collecting sensitive explanations, provide hint text about what not to include and preserve user text through validation and navigation.
  • For server-returned long-answer errors, keep the user's submitted text in the textarea and associate both hint and error messages with the field.
Inspect live examples
TextareaText inputInline validationError summary
Failure modes
  • A paragraph answer is forced into a one-line text input, hiding most of the response.
  • A textarea has no visible label or hint, so users do not know the expected detail or sensitive-data boundary.
  • A character limit exists but no remaining count or too-long recovery is shown until final submit.
  • The field clears a long drafted answer after validation fails.
  • An error summary links to the page but not to the textarea, leaving keyboard users to search for the problem.
  • A rich text editor is used for plain comments and creates formatting, paste, and accessibility problems.

Saved items