Icon Library

An icon library is the set of icons a product draws from. It is chosen once, early, usually quickly — and it is one of the harder decisions to reverse, because by the time the set is wrong it is used in four hundred places.

The criteria are not equally important, and teams weigh them in the wrong order.

Choose on coverage, then licence, then style

Coverage is what cannot be fixed later. Every product has twenty or thirty domain-specific concepts, and if the set does not cover them you will be drawing them yourself, permanently, in a style that never quite matches. Before choosing, list the icons your product actually needs and check them against the set rather than admiring the sample grid.

Licence is a legal question with a cheap answer if you ask it early and an expensive one if you do not.

Style is the most visible criterion and the least consequential. Stroke weight, corner radius and optical size can be adjusted; a missing icon cannot be conjured.

The common sets and their terms

Verified against each project's own licence:

ISC and MIT are functionally equivalent in practice. Font Awesome sits outside this table because it runs a free tier alongside a paid one and the terms differ between them, so read the licence for the tier you intend to use rather than assuming.

The general point matters more than the table: check the licence before the set is in four hundred places, and record which version you took. An icon set that was permissive three years ago can have relicensed since, and nobody notices until procurement asks.

SVG rather than an icon font

Icon fonts render as text, and inherit everything that implies: font smoothing that thins the strokes, baseline alignment that never quite sits right, and — the one that bites — stray glyphs or empty boxes when the font file fails to load.

SVG gives exact control, allows loading only the icons in use, and has no font dependency. The argument for fonts was bundle size and caching, and modern tooling removed it.

Making it a system rather than a folder

One set. Two libraries at different stroke weights never sit together, and the mismatch reads as carelessness rather than as variety.

A size scale, not arbitrary sizes. Two or three sizes tied to your spacing and type scale, so an icon beside 14px text is always the same size.

Colour by token, not by value. An icon should inherit the semantic colour of what it sits in, so theming reaches it.

A documented route for what is missing. Every product needs icons the set does not have. Decide who draws them, to what grid and stroke weight, and where they live — or each team will solve it separately and the set will fragment anyway.

Optical alignment, not mathematical. A play triangle centred by geometry looks off-centre. This is the kind of correction a good library has already made and a hand-drawn addition usually has not.

Icons alone are usually not enough

Icon-only controls are reliably misread. A small set is genuinely universal — a magnifier, an X, a printer — and even those have exceptions across contexts and cultures.

Where space forces icon-only, the control still needs an accessible name and a tooltip, and it should not be the only route to anything important. In dense B2B interfaces this is one of the most common sources of quiet, permanent confusion: a toolbar of eight glyphs that regular users learned two years ago and every new user relearns by trial.

In practice

A team picks a set for its look, ships it, and eighteen months later has forty-one custom icons drawn by five different people.

Reviewing them, the problem is not the drawing. Nobody had agreed a grid or a stroke weight, so the additions vary in both, and several duplicate each other because two squads independently needed the same concept and neither knew the other had drawn it.

The repair is not redrawing forty-one icons. It is a documented grid, one owner, and a place to look before drawing. Redrawing follows, gradually, as screens get touched.

The original choice of set was defensible. The absence of a route for the gap was the failure, and it cost far more than the choice ever could.

Where teams get it wrong

• Choosing on style. The only criterion you can change later.
• Not listing your domain icons first. Coverage is discovered too late to act on.
• Licence checked after adoption. A cheap question asked expensively.
• Two sets. A mismatch that reads as sloppiness.
• No route for what is missing. Every team invents its own, and the set fragments.
• Icon-only toolbars. Learned once by veterans, relearned by everybody else.