ICON OOP's coloured section carries brand marks in their official colours, drawn from CC0 collections rather than converted from monochrome. That distinction matters: an authentic multi-colour logo carries the real gradients and colour relationships, which a recoloured monochrome version cannot reproduce.
The rule worth internalising
Use monochrome when the icon labels something. Use colour when the icon is the thing being identified. A settings gear labels an action, so it should be one colour. A Slack mark identifies Slack, so colour is doing real work.
When colour earns its place
- Brand identification. Payment methods, integrations, tech stacks. Users scan for a colour before they read a name, and colour genuinely speeds recognition here.
- Illustrative moments. Empty states, onboarding screens, feature grids, 404 pages. Places where the icon is the visual content of the block rather than a label on something.
- Category systems with many peers. A file manager with twelve file types, or a dashboard with eight data sources. Colour is a faster discriminator than shape once you are past about six items.
- Emoji and reactions. Where the whole point is expressive colour. See emoji.
When colour actively hurts
- Toolbars and navigation. Coloured icons compete with each other and with your actual call to action. Nothing reads as primary because everything is shouting.
- Table rows and dense lists. At 16px, colour adds noise without adding meaning.
- Anywhere you need hover, focus, disabled and active states. A monochrome icon changes state with one CSS property. A multi-colour icon needs every layer handled.
- Alongside your brand colour. A row of coloured icons next to your primary button makes the button stop looking like a button.
The practical shape of most good interfaces: monochrome throughout the application chrome, colour reserved for brand marks and illustrative blocks.
How multi-colour SVGs are built
A monochrome icon is usually one path with fill="currentColor" or stroke="currentColor". A full-colour icon is several shapes, each with its own explicit fill, sometimes referencing gradient definitions.
<svg viewBox="0 0 24 24">
<defs>
<linearGradient id="g1" x1="0" y1="0" x2="1" y2="1">
<stop offset="0%" stop-color="#4F46E5"/>
<stop offset="100%" stop-color="#EC4899"/>
</linearGradient>
</defs>
<path d="..." fill="url(#g1)"/>
<path d="..." fill="#FFFFFF"/>
</svg>Two consequences follow from this structure, and both catch people out.
Gradient IDs collide. If you inline two different coloured SVGs on the same page and both define a gradient called g1, the second one wins and one of your icons renders in the wrong colours. This is a real bug that appears intermittently and is maddening to debug. Prefix every gradient ID uniquely, or load the icons via <img> so each one gets its own document scope.
File size is higher. Multiple paths plus gradient definitions means a full-colour logo is often three to ten times the size of a monochrome one. Fine for a handful. Not fine for a grid of sixty. The SVG optimisation guide covers reducing this.
Why you cannot recolour them with CSS
The currentColor trick that makes monochrome icons so flexible does not apply here. Each shape has an explicit fill, so setting the CSS color property does nothing.
You can override individual fills if the SVG is inline and the shapes are addressable, but for brand logos you usually should not. Recolouring an official multi-colour mark is prohibited by most brand guidelines. If you need a brand logo in a single colour, use the monochrome version of that mark rather than repainting the colour one. That is precisely why both versions exist. See brand logos and changing icon colour.
Full-colour icons in dark mode
This is the problem most teams discover after shipping dark mode. Full-colour logos are designed for white backgrounds. On a dark background, three things go wrong:
- Marks containing black or near-black elements lose those parts entirely.
- Saturated colours that looked balanced on white become glaring on dark.
- Logos with white knockout areas end up with white shapes floating on dark, which reads as broken.
Three workable fixes, in order of preference. Swap to the monochrome version and set it to your light foreground colour, which is the cleanest answer. Put the logo on a light plate, a white or very light rounded container, which is what many brand guidelines actually recommend. Or serve a different file per theme using a CSS custom property or a picture element with a prefers-color-scheme media query. What does not work is applying a CSS filter to invert the logo, which produces colours that are wrong in every sense.
Colour and accessibility
Two things to get right.
Colour must not be the only signal. If your interface distinguishes states or categories by icon colour alone, users with colour vision deficiency lose that information. Around one in twelve men is affected by some form of red-green colour blindness, which is more than enough to matter. Pair colour with shape, position or a text label.
Meaningful icons still need contrast. Icons that convey information, rather than decorating a label, are expected to meet a 3:1 contrast ratio against their background under WCAG's non-text contrast criterion. Full-colour icons frequently fail this on light backgrounds, particularly pale yellows and light greens. Purely decorative icons are exempt, but be honest about which yours are. Detail in accessible icons.