Badge

A badge is a small, non-interactive marker showing a status or a count. Active, Draft, Overdue. Twelve unread.

The non-interactive part is the definition, and it is what separates it from a chip. A chip can be selected, removed or filtered by; a badge reports and does nothing. Making a badge clickable breaks an expectation the rest of the interface has already taught, and users stop trusting either component.

The two kinds

Status badges name a state: Active, Pending, Failed, Archived. They sit beside the thing they describe, usually in a data table row or on a record header.

Count badges show a quantity: unread messages, items needing attention. They attach to a navigation item or a tab.

They look alike and behave differently, and the most common design mistake is treating count badges as decoration. A count that never reaches zero, or that counts something nobody acts on, teaches people to ignore the one that matters.

Colour is reinforcement, never the message

A meaningful share of users cannot reliably distinguish red from green, and a further share are looking at a screen in sunlight or with a colour profile nobody tested.

The word carries the meaning. "Failed" in red is readable by everybody. A red dot alone is a legend nobody was given.

Keep the palette semantic and small. Four or five states with defined colours, drawn from the same tokens as the rest of the system. A product with eleven badge colours has a taxonomy problem rather than a palette problem.

Contrast still applies. Badges are small text on a coloured fill, which is precisely where WCAG contrast failures cluster. Pale text on a pale tint is the standard version of this mistake.

Counts need rules

Cap them. 99+ rather than 4,271. Past two digits the badge stops communicating magnitude and starts breaking the layout.

Zero should disappear, not display. A badge reading 0 is a control drawing attention to nothing.

Decide what it counts, precisely. Unread, or unresolved, or assigned to me. A count nobody can define is a count nobody can clear, and an uncleaable count is one people learn to ignore within a week.

Announce updates. A badge that changes while somebody is on the page needs a polite live region, or the change is silent to anybody not watching that corner.

In B2B interfaces

One badge per row, ideally. A table where each row carries three badges has moved its information architecture into the badges.

Status vocabulary should match the domain. If the product's users say "Open" and the database says "Active", the badge says Open.

Long values need handling. A status from a customer's own configuration can be twenty characters. Truncate with the full text in the title and the accessible name rather than letting one row set the column width.

Beside the name, not floating. A badge's meaning comes from proximity to what it describes, and in a dense row that proximity is easily lost.

In practice

A product shows six status badges in its main table, colour-coded, with the colours chosen for the palette rather than for meaning.

Support finds that customers routinely misread two of them. "Processing" is amber and "Paused" is a slightly different amber, and in a list of forty rows nobody distinguishes them. The words are there, in small pale text, at a contrast ratio that fails at that size.

Two changes fix it. The two states get visually distinct treatments rather than two shades of one colour, and the text contrast is brought to the threshold. No new states, no new component.

The badges had been technically correct and practically unreadable, which is the characteristic failure of this component.

Where teams get it wrong

• A clickable badge. Breaking the convention the interface taught.
• Colour as the only signal. A legend nobody has.
• Counts with no definition. Uncleaable, and therefore ignored.
• Displaying zero. Attention drawn to nothing.
• Pale text on a pale tint. The contrast failure this component is prone to.
• Three badges per row. Information architecture moved into decoration.