Back to compare picker

Inline message vs Toast notification vs Error state vs Inline validation

Choose inline message when the feedback belongs beside a visible row, panel, step, card, table section, or task area and users may need to read it while continuing nearby work.

Decision dimensions

Dimension Inline messageToast notificationError stateInline validation
UI or UX UI + UX - Contextual in-flow feedbackUI + UX - Transient non-modal status messageUI + UX - Recoverable failure surfaceUI + UX - Field-level validation feedback
UI guidance Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure.Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action.Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step.Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task.Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.Help users correct a specific field without losing or re-entering the value they already typed.
Good UI An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action.Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history.Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI A vague Important message appears above the whole page with no object reference.Five unrelated toasts pile up over the Save and Continue controls.Tiny transient toast for a blocking failure.Only a red border with no message.
Good UX Users can reveal why export is limited, add the missing contact, and see the local message resolve without losing table context.A completed archive action shows a short toast and a specific Undo action because the prior state can be restored.User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.Validation appears after blur or submit when it helps correction.
Bad UX The message disappears like a toast even though users still need the invoice reference.Every autosave tick triggers a toast, training users to ignore real status changes.Clearing work after save failure.Showing errors before users type.
Best fit A visible object or section has local status, warning, success, or next-step information.Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export.A system or task failure blocks expected content or action.A single field has a specific correctable problem.
Avoid when The message is a one-field validation correction.The message is the only recovery path for a blocking or high-consequence failure.Nothing exists yet and the state is expected.The main recovery task is finding several errors across a submitted page.
Required state Neutral local context with no message.Idle state with no visible toast and a reachable status or history region when applicable.Normal expected state before failure.Neutral field with label, hint, and no error.
Accessibility burden Keep the message in the reading order near the context it describes.Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement.Use appropriate alert or status semantics for newly appearing critical errors.Expose invalid state on the input and connect error text to the field description where possible.
Common misuse Using an inline message for a single field error that should be connected to that input.Using a toast as the only feedback for payment, save, permission, upload, or security failures.Using a transient toast for critical errors.Showing field errors before users have interacted with the control.

Inline message

UI or UX
UI + UX - Contextual in-flow feedback
UI guidance
Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure.
UX guidance
Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step.
Good UI
An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action.
Bad UI
A vague Important message appears above the whole page with no object reference.
Good UX
Users can reveal why export is limited, add the missing contact, and see the local message resolve without losing table context.
Bad UX
The message disappears like a toast even though users still need the invoice reference.
Best fit
A visible object or section has local status, warning, success, or next-step information.
Avoid when
The message is a one-field validation correction.
Required state
Neutral local context with no message.
Accessibility burden
Keep the message in the reading order near the context it describes.
Common misuse
Using an inline message for a single field error that should be connected to that input.

Toast notification

UI or UX
UI + UX - Transient non-modal status message
UI guidance
Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action.
UX guidance
Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task.
Good UI
Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history.
Bad UI
Five unrelated toasts pile up over the Save and Continue controls.
Good UX
A completed archive action shows a short toast and a specific Undo action because the prior state can be restored.
Bad UX
Every autosave tick triggers a toast, training users to ignore real status changes.
Best fit
Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export.
Avoid when
The message is the only recovery path for a blocking or high-consequence failure.
Required state
Idle state with no visible toast and a reachable status or history region when applicable.
Accessibility burden
Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement.
Common misuse
Using a toast as the only feedback for payment, save, permission, upload, or security failures.

Error state

UI or UX
UI + UX - Recoverable failure surface
UI guidance
Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance
Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI
Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI
Tiny transient toast for a blocking failure.
Good UX
User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX
Clearing work after save failure.
Best fit
A system or task failure blocks expected content or action.
Avoid when
Nothing exists yet and the state is expected.
Required state
Normal expected state before failure.
Accessibility burden
Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse
Using a transient toast for critical errors.

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
  • Choose inline message when the feedback belongs beside a visible row, panel, step, card, table section, or task area and users may need to read it while continuing nearby work.
  • Choose toast notification when the message is short, non-blocking, and safely disposable or recoverable from history after a few seconds.
  • Choose error state when expected content, saving, sync, payment, permission, or computation failed and the affected area needs persistent recovery controls.
  • Choose inline validation when the message is tied to one input value and tells users exactly how to correct that field.
  • Use inline message for contextual warnings such as selected customers missing billing contacts, export limitations, draft conflict notes, or local success that should stay near the affected object.
  • Do not use inline message as a detached page banner; if the message affects the whole page, service, or site, use the appropriate page-level or global feedback surface.
  • Do not place a large troubleshooting workflow inside an inline message; include one local action or disclosure and route deeper repair to an error state, panel, page, or dialog.
  • Announce dynamic inline messages as status or alert according to urgency without moving focus unless the user requested the message or must act immediately.
Inspect live examples
Failure modes
  • A warning about one table row appears at the top of the page, so users cannot tell which item is affected.
  • A field-format correction is shown as a section message instead of being attached to the input.
  • A blocking load failure is reduced to a small inline note without retry or fallback.
  • A success toast disappears even though users need to copy the generated reference beside the object.
  • A local message contains several unrelated links, long support instructions, and multi-step form fields.
  • A dynamic inline warning appears visually but is not announced to assistive technology.