Status Colors in UI: Success, Warning, Error and Info

Status colours form a small language inside a product. Green often suggests success, amber suggests caution, red suggests error, and blue suggests information, but familiar associations do not make any particular swatch suitable. Each status needs enough range to work as a quiet message, a strong label, and a visible boundary without overwhelming ordinary content.

List the meanings before selecting swatches

Write one plain-language definition for success, warning, error, and information. Success confirms a completed outcome; warning identifies a condition needing attention; error marks a failed or invalid state; information supplies context without implying a problem. Product-specific exceptions should be explicit rather than hidden in colour choices.

Use the contrast checker to evaluate an initial dark foreground and pale background for each status. Choose pairs, not isolated colours. A vivid red brand chip might look compelling in a palette presentation while offering no suitable role as small text or a broad alert surface.

Separate the brand accent from the semantic family even when their initial values match. A blue primary action and a blue information message can share a hue, but they do not share a meaning. Their values may need to diverge later without altering every use of blue.

Review the W3C guidance on use of colour. The palette should support explicit labels and recognizable cues, not replace them. This article focuses on choosing colours; a complete accessibility review includes additional considerations beyond the palette itself.

Give each status a small working range

For every status, define a pale surface, a visible edge, a strong foreground, and optionally a solid fill. These values solve different problems. The best text colour is not necessarily the most attractive fill, and a subtle border may be too weak to carry meaningful information alone.

Start with consistent visual weight across statuses. If the warning surface is far more saturated than the error surface, routine cautions may dominate serious failures. Equal numeric saturation does not solve this because yellow, red, blue, and green have different perceived brightness and gamut limits.

Put the four pale surfaces side by side with the same message length. Then compare their solid versions at identical sizes. Adjust lightness and chroma until the hierarchy reflects severity and intended use, rather than the accidental intensity of a hue.

Avoid requiring all statuses to use white text. Yellow and amber frequently work better with dark foregrounds unless their fills are made much darker. The desired semantic association can survive a change in text polarity; forcing white text can produce an unnecessarily muddy warning colour.

Express paired values clearly in CSS

Keep semantic roles visible in the values you export. A small application can start with complete foreground and background tokens rather than a large primitive scale. The essential requirement is that consumers use approved pairs instead of improvising combinations.

:root {
--success-bg: #edf8f0;
--success-fg: #205b31;
--warning-bg: #fff4d6;
--warning-fg: #684b00;
--error-bg: #fff0ef;
--error-fg: #922b28;
--info-bg: #edf4ff;
--info-fg: #214f86;
}

.status-message[data-status="warning"] {
color: var(--warning-fg);
background: var(--warning-bg);
}

These values are candidate pairs, not a guarantee for every use. Verify the actual rendered combinations and any additional border or icon. An icon that uses a lighter accent than the text may disappear even though the text itself remains clear.

The MDN custom properties guide explains the mechanism for reusing the values. For a broader handoff approach, see design tokens basics, while keeping the colour review centred on meaning and visual distinction rather than token architecture.

Keep semantic hues distinguishable in context

A green success message beside a teal brand accent can blend into the surrounding page. An orange brand palette can make warning treatments look routine. Context changes salience, so review status colours alongside the existing accent, neutrals, and common data colours.

Test realistic clusters: one warning among ordinary rows, an error beside a primary action, and an informational note beneath a success confirmation. A four-swatch display cannot reveal these collisions. Use actual wording so that message density and colour area resemble the final experience.

Use the colour converter to normalize incoming values from different design files before comparing them. A near-duplicate blue can look like a semantic distinction in a document while being practically indistinguishable in the browser. Consolidate accidental duplicates, not intentional role differences.

Do not rely on hue alone to communicate severity. Add words such as “Warning” or “Failed” where interpretation matters, and retain stable placement or other visible cues. This also prevents the colour language from becoming opaque when content is printed, recoloured, or viewed under unfavourable display conditions.

Validate expansion before freezing the palette

Try longer messages, dense tables, and small badges. A colour that works as a broad pale banner may feel too weak in a compact marker. Conversely, a saturated badge colour can become overwhelming when expanded into a full-width alert background.

Match intensity to area while preserving meaning. The same warning family can use a pale surface in a message and a stronger mark in a short label. Document these variants so that contributors do not create new oranges every time the content density changes.

Use the W3C contrast explanation to understand text-pair evaluation, and keep a record of measured pairs. If transparency or imagery is involved, flatten or inspect the actual rendered backdrop rather than measuring only the original source values.

Finally, define what happens when multiple statuses appear together. Reserve the strongest colour treatment for the information requiring the greatest attention, not automatically the most recent message. A coherent semantic palette is a coordinated set of relationships, not four independently polished brand colours.

Key takeaways

• Define meaning first, then choose foreground-background pairs.
• Give each status surfaces, foregrounds, and edges appropriate to its uses.
• Balance visual weight rather than forcing equal numeric saturation.
• Keep semantic roles separate from brand accents, even when hues overlap.
• Confirm meaning with words and other cues, and test realistic status clusters.