Colour at small sizes

The colour you specified is not the colour the user sees, when the colour is small enough.

This sounds like an exaggeration. It is not. A colour that the designer picked at a 200px square preview, on a calibrated monitor, in a bright office, is rendered to the user as a different colour when the same hex value is applied to a single line of 14px body text on a phone, in a sunlit room, with the user holding the phone at arm’s length. The hex value is the same. The perceived colour is not.

A few specific patterns that are worth knowing.

Saturation reads lower at small sizes. The same hex value, applied to a 16px line of text, looks duller than the same hex applied to a 200px block of the same colour. The eye cannot see the saturation in a small enough sample. Designers who pick body-text colours at the same saturation as the heading colours produce body type that reads as muddier than the headings, even though the values are the same.

The fix, on most projects, is to pick body-text colours slightly more saturated than the visual eye thinks they should be. The text reads correctly at size. The text would look loud at heading scale, which is fine, because it is not being used at heading scale.

Contrast is non-linear with size. WCAG contrast ratios assume a single threshold for “large text” (18pt or 14pt bold) and a different threshold for “small text”. The reality is more continuous. Text at 12px needs noticeably higher contrast than text at 16px to read as clearly. The contrast ratio that passes WCAG AA at 16px will, in practice, be tiring to read at 12px.

The studio’s default, since this became more obvious to me, is to set body text contrast at least one full grade above the WCAG minimum, and to set small UI text (footer notes, captions, metadata) closer to two grades above. The reading experience at the smallest sizes is substantially improved.

Colour shifts with the surrounding colour. The same hex value, on a cream background, looks warmer than on a white background. Same value, on a dark background, looks cooler than on a light background. Designers who pick colour values in isolation, at the colour-picker preview level, end up with palettes that look different when applied to the actual page than they did in the picker.

The fix is to pick colour values in context. The Figma file should preview the colour at the size and against the background it is going to be used on. The colour-picker swatch on its own is a misleading reference.

Hairline borders are darker than they should be. A 1px line, at the same lightness value as a 2px line, looks darker because the eye cannot resolve it well enough to see the lightness. Sites that use 1px borders at the same hex value as their background dividers tend to look noisier than they intend.

The fix, where the studio uses hairline borders, is to set the border colour 5-10% lighter than the divider colour the eye expects. The hairline reads as a hairline, not as a heavy line.

The single book on this that has been most useful to me is Interaction of Color by Josef Albers, the 50th-anniversary edition. From 1963. Almost everything in this post is a footnote to it. The book is short. Read it twice.

Two practical tools to keep open while doing this work: oklch.com for picking values in a perceptually-uniform space, and Stark for contrast and small-text checks against WCAG. The companion piece on three colour pickers and the wrong one covers the underlying argument for OKLCH.

Most of the colour problems on most small-business sites are problems of size and context, not of hex value. The studios that handle this well do not pick perfect colours. They pick colours that survive being applied at the sizes the brand actually uses. The difference is subtle on the file and substantial on the page.