Tag / status tag vs Filter chips vs Chip selection vs Inline message

Choose tag when the UI needs a compact read-only label that describes an object's category, state, phase, count, or freshness without becoming an action.

Tag / status tag live example Filter chips live example Chip selection live example Inline message live example

Decision dimensions

Dimension	Tag / status tag	Filter chips	Chip selection	Inline message
UI or UX	UI + UX - Compact static category or status label attached to an object	UI + UX - Compact chip set for toggling or removing result filters	UI + UX - Compact selectable chip group for short choice answers	UI + UX - Contextual in-flow feedback
UI guidance	Render a tag as a short non-interactive label attached to the object, row, card, heading, count, or result it describes, using stable placement and a visual weight lower than the object's title or primary action.	Render filter chips as a compact set of short, consistently styled controls near the content they filter, with clear selected, unselected, focused, disabled, and removable states.	Render a labelled chip group with short chip labels, visible selected and unselected states, focus states, disabled states, optional selected checkmarks, and inline help or error text.	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 tag when a compact label helps users scan, compare, prioritize, or understand an object's state without opening a message, filter control, or detail panel.	Use filter chips for quick, low-cost filtering when users can understand the available criteria at a glance and combine a few chips without opening a larger panel.	Use chip selection when users answer a lightweight choice question from a small visible set and the labels are short enough to scan as chips.	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	A claims table shows status tags such as Pending review, Approved, and Needs evidence in the Status column, with semantic colors and the same text used in detail views.	A search results page shows chips for Open, Urgent, Appeals, and Benefits below the search box, with selected chips using a checkmark and stronger background.	An onboarding form asks Choose up to 3 interests and shows compact chips for Design, Data, Research, AI, Accessibility, and Mobile with selected checkmarks.	An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action.
Bad UI	A tag labelled Click to approve looks like a small button but is not keyboard focusable or actionable.	A single pill labelled Filter sits alone and behaves like a vague button.	A chip row contains selectable answers, removable tags, links, and action chips with identical styling.	A vague Important message appears above the whole page with no object reference.
Good UX	A reviewer sorts a queue by due date, then uses Needs evidence tags to triage records that require outreach without opening each record first.	A user taps Urgent and Appeals, sees the result count drop immediately, then removes Appeals without losing the search query or sort order.	A user selects Design, Data, and Accessibility, sees 3 of 3 selected, then receives immediate feedback when trying to add a fourth chip.	Users can reveal why export is limited, add the missing contact, and see the local message resolve without losing table context.
Bad UX	A user tries to remove a category tag because it looks like an active filter chip, but the page gives no response.	Tapping a chip changes the page route and clears the result context.	A user taps a chip expecting to answer a question, but the page filters content instead.	The message disappears like a toast even though users still need the invoice reference.
Best fit	A compact category, state, phase, freshness marker, priority, or count helps users scan a group of objects.	A few common filters should stay visible and directly toggleable near the content.	Users answer a lightweight choice question from a small set of short labels.	A visible object or section has local status, warning, success, or next-step information.
Avoid when	Users need to click, remove, select, or edit the label.	There are many criteria, ranges, dates, or grouped fields that need a panel or form.	The chips filter a result set rather than collect an answer.	The message is a one-field validation correction.
Required state	Neutral category tag attached to a row, card, heading, or object summary.	Unselected chip set state with no active filters and a clear result count.	Empty chip group with visible question label and helper text.	Neutral local context with no message.
Accessibility burden	Do not rely on color, icon, or shape alone to express semantic status.	Use button semantics for interactive chips and expose selected state with aria-pressed or equivalent semantics.	Give the chip group a visible label and programmatic group name.	Keep the message in the reading order near the context it describes.
Common misuse	Making a static tag look clickable or focusable.	Using a lone chip as a generic Filter button.	Using chip selection to filter result sets without explaining that the chips are filters.	Using an inline message for a single field error that should be connected to that input.

Tag / status tag

UI or UX: UI + UX - Compact static category or status label attached to an object
UI guidance: Render a tag as a short non-interactive label attached to the object, row, card, heading, count, or result it describes, using stable placement and a visual weight lower than the object's title or primary action.
UX guidance: Use tag when a compact label helps users scan, compare, prioritize, or understand an object's state without opening a message, filter control, or detail panel.
Good UI: A claims table shows status tags such as Pending review, Approved, and Needs evidence in the Status column, with semantic colors and the same text used in detail views.
Bad UI: A tag labelled Click to approve looks like a small button but is not keyboard focusable or actionable.
Good UX: A reviewer sorts a queue by due date, then uses Needs evidence tags to triage records that require outreach without opening each record first.
Bad UX: A user tries to remove a category tag because it looks like an active filter chip, but the page gives no response.
Best fit: A compact category, state, phase, freshness marker, priority, or count helps users scan a group of objects.
Avoid when: Users need to click, remove, select, or edit the label.
Required state: Neutral category tag attached to a row, card, heading, or object summary.
Accessibility burden: Do not rely on color, icon, or shape alone to express semantic status.
Common misuse: Making a static tag look clickable or focusable.

Filter chips

UI or UX: UI + UX - Compact chip set for toggling or removing result filters
UI guidance: Render filter chips as a compact set of short, consistently styled controls near the content they filter, with clear selected, unselected, focused, disabled, and removable states.
UX guidance: Use filter chips for quick, low-cost filtering when users can understand the available criteria at a glance and combine a few chips without opening a larger panel.
Good UI: A search results page shows chips for Open, Urgent, Appeals, and Benefits below the search box, with selected chips using a checkmark and stronger background.
Bad UI: A single pill labelled Filter sits alone and behaves like a vague button.
Good UX: A user taps Urgent and Appeals, sees the result count drop immediately, then removes Appeals without losing the search query or sort order.
Bad UX: Tapping a chip changes the page route and clears the result context.
Best fit: A few common filters should stay visible and directly toggleable near the content.
Avoid when: There are many criteria, ranges, dates, or grouped fields that need a panel or form.
Required state: Unselected chip set state with no active filters and a clear result count.
Accessibility burden: Use button semantics for interactive chips and expose selected state with aria-pressed or equivalent semantics.
Common misuse: Using a lone chip as a generic Filter button.

Chip selection

UI or UX: UI + UX - Compact selectable chip group for short choice answers
UI guidance: Render a labelled chip group with short chip labels, visible selected and unselected states, focus states, disabled states, optional selected checkmarks, and inline help or error text.
UX guidance: Use chip selection when users answer a lightweight choice question from a small visible set and the labels are short enough to scan as chips.
Good UI: An onboarding form asks Choose up to 3 interests and shows compact chips for Design, Data, Research, AI, Accessibility, and Mobile with selected checkmarks.
Bad UI: A chip row contains selectable answers, removable tags, links, and action chips with identical styling.
Good UX: A user selects Design, Data, and Accessibility, sees 3 of 3 selected, then receives immediate feedback when trying to add a fourth chip.
Bad UX: A user taps a chip expecting to answer a question, but the page filters content instead.
Best fit: Users answer a lightweight choice question from a small set of short labels.
Avoid when: The chips filter a result set rather than collect an answer.
Required state: Empty chip group with visible question label and helper text.
Accessibility burden: Give the chip group a visible label and programmatic group name.
Common misuse: Using chip selection to filter result sets without explaining that the chips are filters.

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.

Decision rules

Choose tag when the UI needs a compact read-only label that describes an object's category, state, phase, count, or freshness without becoming an action.
Choose a status tag only when the label reports current state, progress, urgency, priority, or outcome and the semantic color has the same meaning everywhere it appears.
Choose filter chips when the label represents an active filter that users can remove, clear, or edit and the result set changes when it is removed.
Choose chip selection when the chip itself is an input option and users can select or deselect it as part of a form, preference, or filtering control.
Choose inline message when users need more than a compact label: a local title, explanatory sentence, recovery action, detail disclosure, or status announcement tied to a row, card, or section.
Do not make a read-only tag look keyboard-focusable, clickable, hoverable, or dismissible; that turns it into a chip, link, button, or menu trigger.
Do not rely on color alone for status tags; the visible text and surrounding object context must still identify the state or category.
Do not place several unrelated tags on every object just because metadata exists; tags should speed scanning by exposing the few labels users use to compare or prioritize.
Do not use tag as the object's title, primary identifier, alert, validation error, or full status explanation; those belong to heading, alert, inline validation, or inline message patterns.

Inspect live examples

Tag / status tag Filter chips Chip selection Inline message

Failure modes

A read-only status tag receives focus and looks removable, so keyboard users try to activate it and nothing happens.
A table uses red, green, and blue tags with vague labels such as Type A and Level 2, so users cannot tell which states need attention.
Every record has eight metadata tags, making the row harder to scan than plain columns.
An active filter is rendered as a static tag with no remove control, trapping users in a narrowed result set.
A one-word tag tries to replace an inline warning that needs a reason and a next step.