SaaS Tags, Labels & Chips: Real Screenshots & UX Patterns (2026)

Tags, labels, and chips are the small coloured tokens scattered across almost every SaaS product — the status pill on a support ticket, the coloured label on a GitHub issue or a Linear task, the assignee avatar-chip on a card, the category attached to a document, the filter token that appears in the search bar when you narrow a list. They are how the product lets people impose their own structure on their own data: this ticket is urgent, this task is blocked, this contact is a customer, this doc is a draft. And precisely because each one is tiny and feels like a finishing touch, they are usually built on autopilot — pick a component, assign a colour, ship it — with no thought given to the vocabulary behind them, the meaning of the colours, or what happens when a record collects fifteen of them. Then they quietly become one of the messiest, most confusing surfaces in the product. A team invents its own private colour code that no new member can decode. An open tagging field grows to four hundred near-duplicate tags ("bug", "Bug", "bugs", "defect") that make filtering useless. Pills so saturated and loud they pull the eye away from the actual content they are meant to annotate. Filter chips that give no hint they can be removed, so people cannot work out how to clear the filter they accidentally set. The tokens are small; the confusion they create compounds across every list, board, and detail view in the app.

Timely

Productivity·Dashboard

View all

Timely — a real dashboard screen from the SaaSUI library.

The root problem, as with so many small components, is that three different things get called the same name and built the same way. A label or tag is user-applied metadata: a person attaches it to categorise something, from a fixed set or a free-form field, and it means whatever the team has decided it means. A status badge is system-assigned state: the product sets it to reflect where something is — active, paused, overdue, published, failed — and the user usually cannot type a new one. An input chip or filter token is interactive: it represents a current selection or filter, it is explicitly removable, and it exists to be manipulated, not just read. These call for different rules. A label needs a governed vocabulary and a way to add new ones; a status badge needs a small, consistent, legible set that maps cleanly to states; a filter chip needs an unmistakable remove affordance and a clear relationship to the results it is narrowing. Treat them all as "a coloured pill" and you get the familiar failures: open tagging where you needed controlled statuses, un-removable chips where people expected to clear a filter, a status set that quietly sprawls until it means nothing. This guide draws those lines and then walks the patterns that make each token behave — vocabulary, colour and meaning, visual weight, add and remove, and overflow — each shown with real SaaS screenshots so you can see how shipped products keep the smallest labels in the interface useful instead of letting them turn into noise.

First, know which one you are building: tag vs status badge vs filter chip

Before choosing a colour or a component, decide which of the three tokens the situation actually calls for, because they are not interchangeable and the most common mistake is reaching for the wrong model. Use a label or tag when a person is applying their own metadata to categorise or organise something — a topic on a note, a "customer" marker on a contact, a priority a human sets, a team-defined category. Tags are user-controlled, often drawn from an editable vocabulary, and their meaning belongs to the team. Use a status badge when the system is reporting state that the user reads but does not freely author — active, trialing, past due, published, draft, failed, syncing. Status badges come from a small, fixed, product-defined set and should look consistent everywhere the same state appears. Use an input chip or filter token when the token represents an interactive selection the person is meant to manipulate — the values in a multi-select, the filters currently applied to a list, the recipients on a message. Chips are removable by definition and exist to be added and cleared. The test is simple: is a person categorising (tag), is the system reporting (status badge), or is a person selecting and removing (chip)? Get this wrong and the failures are specific: build an open free-text tag where you needed a fixed status and the "state" of your records fragments into inconsistent spellings; build a read-only badge where people expected a removable filter chip and they cannot work out how to clear it; let users invent statuses and the concept of state stops being reliable. Naming which of the three you are building is the decision every other rule below depends on.

Toggl Track

Productivity·Dashboard

View all

Toggl Track — a real dashboard screen from the SaaSUI library.

Decide the vocabulary: controlled, open, or a governed mix

The single biggest determinant of whether tags help or rot is the vocabulary behind them, and this is the decision teams most often skip. A controlled vocabulary — a fixed, curated set people choose from but cannot freely extend — keeps things consistent and filterable: statuses, priorities, and stages should almost always be controlled, because their whole value is that "urgent" means exactly one thing everywhere. An open vocabulary — a free-text field where anyone can create a new tag on the fly — is flexible and fast but degrades without guardrails: left ungoverned it sprawls into hundreds of near-duplicates ("frontend", "front-end", "FE", "front end") that splinter the very grouping tags were supposed to provide, and filtering by them becomes hopeless. The mature answer is usually a governed middle: let people add tags, but help them reuse existing ones instead of minting duplicates. That means an autocomplete that surfaces matching existing tags as they type ("front" offers "frontend" before they invent "front-end"), case-insensitive matching so capitalisation does not fork a tag, a visible existing-tag list so creation is a deliberate act rather than the default, and an admin surface to merge, rename, and retire tags as the set drifts. The distinction people forget is that statuses and tags are different in kind: a status set should be closed and small and rarely change; a tag set can be open but needs curation to stay useful. Deciding this up front — which fields are controlled, which are open, and how open ones are kept clean — is what separates a tagging system that gets better as data accumulates from one that collapses under its own weight after a few busy months.

Tray

Automations·Dashboard

View all

Tray — a real dashboard screen from the SaaSUI library.

Use colour to reinforce meaning — but never as the only signal

Colour is what makes tags and badges scannable, and it is also where they most often fail two ways at once: by meaning nothing and by excluding people. Colour earns its place when it maps consistently to meaning — the same red for every "overdue", the same green for every "active" — so people learn the code once and read state at a glance across the whole product. It fails when it is decorative and arbitrary: a rainbow of tag colours assigned at random carries no information, adds visual noise, and forces people to read every label anyway, so the colour was pure cost. Worse, a private colour code that only the original team understands ("purple means escalated, obviously") is a barrier to every new user and every cross-team hand-off. But the deeper, non-negotiable rule is that colour must never be the only signal, because a meaningful share of users cannot distinguish the colours you are relying on. Colour-blind users cannot separate a red "failed" chip from a green "passed" one if colour is the sole difference; anyone on a poor screen or in bright light is in the same position. So every tag and badge needs a text label as its primary carrier of meaning, with colour as reinforcement — and where state genuinely must be distinguishable at a glance, pair colour with a second cue: an icon, a shape, a dot, a different border, or the text itself. The text-plus-colour combination is what makes a status set both fast to scan for sighted mouse users and fully legible to everyone else. A wall of colour-only pills looks designed and is quietly broken; labelled tokens where colour supports the words are the ones that actually work for the whole audience.

Trello

Project Management Software·Dashboard

View all

Trello — a real dashboard screen from the SaaSUI library.

Match visual weight to importance so tokens annotate, not shout

A tag is metadata about content; it is not the content, and its visual weight should reflect that. The most common aesthetic failure in this whole category is pills so saturated, large, and loud that they out-compete the thing they are attached to — a task title in calm grey with three neon-filled tags blazing beside it, so the eye goes to the labels and skims the actual work. Good tag and badge styling is quiet by default: subtle backgrounds, restrained fills, enough contrast for the text to be legible but not so much that a row of them becomes a strip of flashing colour. Reserve stronger, higher-contrast treatment for the few tokens that genuinely warrant attention — a hard "overdue" or "failed" or "blocked" state that should catch the eye — and let the everyday categorising tags recede. This is a hierarchy decision: not every token deserves the same visual force, and treating them all as loud means none of them stand out when it matters. Density compounds the problem — a board or table where every row carries several full-colour pills reads as chaotic even when each individual pill is fine, because the aggregate is a quilt of competing colour. The fixes are restraint (mute the routine tokens), hierarchy (let only meaningful states be loud), and often consistency of shape and size so a row of tokens reads as an orderly set rather than a jumble. Solid, mature products tend toward understated tags with occasional deliberate emphasis; products that let every label shout end up with interfaces that feel busy and stressful no matter how clean the underlying layout is. The point of a tag is to help someone find and understand content faster, not to decorate it into illegibility.

Twilio

Communications·Dashboard

View all

Twilio — a real dashboard screen from the SaaSUI library.

Make add and remove obvious, especially for interactive chips

Tokens that people create and clear — tags they apply, chips that filter a list, values in a multi-select — live or die on whether the add and remove affordances are discoverable, and this is where read-only thinking silently breaks interactive tokens. Adding a tag should have an obvious entry point: a clear "add" control or an input that plainly accepts new tokens, with the autocomplete described above so people reuse rather than duplicate. Removing is the part most often botched. A filter chip or an applied tag that the person is meant to be able to clear needs an unmistakable remove affordance — the familiar small close control on the chip, revealed clearly and reliably (not only on hover, which fails on touch), so people can see that the token is dismissible. The classic failure is a filter that appears as a plain-looking pill with no visible way to remove it: the person set a filter, cannot tell the chip is removable, and has no idea how to get back to the full list — a dead end created by a token that looked static but was supposed to be interactive. Two more rules protect the pattern. First, distinguish removable chips from read-only badges visually, so people are not hunting for a close control on a status badge that was never meant to be dismissed, nor missing one on a chip that was. Second, make bulk clearing possible when several chips stack up — a "clear all" for a set of active filters — because removing tokens one by one when someone just wants the unfiltered view is needless friction. On touch especially, the remove target must be large enough to hit and not dependent on hover to appear. The principle is that an interactive token must advertise its interactivity: if a person can add it, the way to add is obvious; if they can remove it, the way to remove is visible and reachable on every input they use.

Typeform

Form Builder·Dashboard

View all

Typeform — a real dashboard screen from the SaaSUI library.

Handle the many-tags case before it handles you

Every tagging system that gets used eventually meets the record with too many tags, and whether that case was designed for is what separates a system that scales from one that falls apart in busy accounts. A contact with twelve tags, an issue with eight labels, a filter bar with six active chips — if the layout simply lets them all render at full size, they wrap into several lines, blow out row heights in a table, push other content off screen, and turn a tidy list into a ragged mess. Designing for overflow means deciding in advance what happens when tokens exceed the space: show the first few and collapse the rest behind a compact "+5 more" affordance that expands on demand; keep token rows to a bounded height so a heavily-tagged record does not distort the whole table; and, in dense contexts like a table cell, consider showing only the most important tokens with the full set available on click or hover-with-touch-fallback. The same discipline applies to filter chips — a long row of active filters should stay on one controlled line with an overflow count rather than wrapping into a growing block that shoves the results down the page. There is a content dimension too: long individual tag names ("Q3-2026-enterprise-migration-blocked") need truncation with the full text available, so one verbose tag does not stretch a column. The failure mode is always the same — a design that looks fine with two tokens and disintegrates at twelve — and the fix is always to treat the crowded case as the real case, not the exception. Because in any product people actually use, records accumulate tags, filters stack up, and the many-token state is where the interface is truly tested. Solid products cap, collapse, and truncate gracefully; fragile ones let a well-tagged record wreck the layout.

The details that separate a considered tag system from coloured clutter

Each rule above is small on its own; a product’s tags, labels, and chips feel deliberate when they are handled together. These are the behaviours mature SaaS products share across boards, tables, detail views, and filter bars.

• The right token is chosen for the job: user-applied metadata is a tag, system-reported state is a status badge, and an interactive removable selection is a chip — and each follows its own rules rather than all being "a coloured pill".
• Statuses and priorities use a controlled, small, consistent vocabulary; open tag fields are governed with autocomplete on existing tags, case-insensitive matching, and an admin merge/rename surface so they do not sprawl into duplicates.
• Colour maps consistently to meaning and is never the only signal — every token carries a text label, and states that must be distinguished at a glance pair colour with an icon, shape, or dot for colour-blind and low-contrast users.
• Routine categorising tokens are visually quiet; stronger, higher-contrast treatment is reserved for the few states (overdue, failed, blocked) that genuinely warrant attention, so tokens annotate content instead of drowning it.
• Interactive chips advertise their interactivity: adding has an obvious entry point, and removing shows a clear close affordance that is reachable on touch, not hidden behind hover.
• Removable chips are visually distinct from read-only status badges, so people are neither hunting for a close control that was never meant to exist nor missing one that should.
• When several filter chips stack up, a "clear all" exists so people are not removing tokens one at a time to get back to the unfiltered view.
• The many-tags case is designed for: tokens collapse behind a "+N more" affordance, rows stay a bounded height, and long individual tag names truncate with the full text available.
• Token shape and size are consistent so a row reads as an orderly set, and colour density is kept in check so a board or table does not become a quilt of competing pills.

Common SaaS tag, label, and chip mistakes

• Using an open free-text tag where a controlled status was needed, so record "state" fragments into inconsistent spellings and filtering becomes useless.
• An ungoverned tag field with no autocomplete or case-insensitive matching, sprawling into hundreds of near-duplicate tags after a few busy months.
• Colour used as the only signal, locking out colour-blind users and anyone on a poor screen because a red "failed" and green "passed" differ only by hue.
• A private, arbitrary colour code that only the original team understands, meaningless to every new user and cross-team hand-off.
• Pills so saturated and loud they out-compete the content they annotate, so the eye goes to the labels and skims the actual work.
• A filter chip with no visible remove affordance, so people cannot tell it is removable and get stranded unable to clear a filter they set.
• Remove controls that only appear on hover, invisible and unusable on touch screens.
• No "clear all" for a stack of active filter chips, forcing people to remove tokens one by one to reach the unfiltered view.
• The many-tags case ignored, so a heavily-tagged record wraps into multiple lines, blows out row heights, and wrecks the table layout.

Frequently asked questions

What is the difference between a tag, a status badge, and a filter chip?

They are three different tokens for three different jobs, and building them the same way is the root of most tag-related mess. A tag or label is user-applied metadata: a person attaches it to categorise or organise something, often from an editable vocabulary, and it means whatever the team decides. A status badge is system-assigned state that the user reads but does not freely author — active, paused, overdue, published, failed — drawn from a small, fixed, product-defined set that should look identical everywhere the same state appears. A filter chip or input chip is interactive: it represents a current selection or applied filter, it is explicitly removable, and it exists to be manipulated rather than just read. The test for which you need is whether a person is categorising (tag), the system is reporting (status badge), or a person is selecting and removing (chip). Getting it wrong produces specific failures: an open free-text tag where you needed a fixed status fragments your records into inconsistent spellings; a read-only badge where people expected a removable chip strands them unable to clear a filter; letting users invent statuses makes the concept of state unreliable. Naming which of the three you are building is the decision every colour, vocabulary, and affordance choice depends on.

Why should colour never be the only way a tag or badge conveys meaning?

Because a meaningful share of users cannot reliably distinguish the colours you are relying on, so colour alone locks them out. Colour-blind users cannot separate a red "failed" chip from a green "passed" one if hue is the only difference between them; anyone on a low-quality screen, in bright sunlight, or with a display in a different colour profile is in a similar position. That is why every tag and badge needs a text label as its primary carrier of meaning, with colour as reinforcement rather than the sole signal — and where a state genuinely must be distinguishable at a glance, colour should be paired with a second cue such as an icon, a shape, a dot, or a distinct border. Colour still does real work when it maps consistently to meaning (the same red for every overdue, the same green for every active), letting people learn the code once and scan state across the product; the failure is decorative, arbitrary, or private colour that carries no shared information and, when it is the only signal, excludes part of your audience entirely. The reliable pattern is text plus colour: fast to scan for sighted users, and fully legible to everyone else.

How do you stop an open tagging system from sprawling into hundreds of duplicate tags?

By governing the open field instead of leaving it a raw free-text box. The core mechanism is an autocomplete that surfaces matching existing tags as the person types, so "front" offers the existing "frontend" before they invent "front-end", nudging reuse over creation. Pair that with case-insensitive matching so capitalisation does not fork a tag into "Bug" and "bug", a visible list of existing tags so creating a new one is a deliberate act rather than the path of least resistance, and an admin surface to merge, rename, and retire tags as the set inevitably drifts. It also helps to decide, field by field, which things should be open tags at all and which should be a controlled set: statuses, priorities, and stages should almost always be a fixed, curated vocabulary because their value depends on meaning exactly one thing everywhere, while genuinely open-ended categorisation can be a governed open field. The distinction people forget is that tags and statuses are different in kind — a status set should be closed, small, and rarely change; a tag set can be open but needs curation to stay useful. A system that both encourages reuse at creation time and allows clean-up over time gets more useful as data accumulates, instead of collapsing under near-duplicate tags after a few busy months.

Study real SaaS tags, labels, and chips in the SaaSUI library

Every pattern above is easier to apply when you can see how real products solved it. Browse real tags, labels, status badges, priority pills, filter chips, and assignee tokens — controlled and open vocabularies, colour paired with text, quiet visual weight, clear add and remove affordances, and graceful overflow — from shipped SaaS applications like Linear, Notion, GitHub, Stripe, Asana and other polished tools in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products keep the smallest labelling tokens useful without letting them turn into coloured clutter.