Icons are a set, not a collection

Why mixed icons look wrong

Download three icons from three sources and put them in a row. They will not match, and the mismatch will be visible to people who cannot name any of the reasons.

The reasons are specific and measurable:

• Different grids. One set is drawn on 24 pixels, another on 20, another on 16 and scaled up.
• Different stroke weights. 1.5px against 2px is a visible difference in apparent weight.
• Different corner treatments. Rounded caps and joins against square ones.
• Different levels of detail. One set draws a camera with a lens and a flash, another with a rectangle and a circle.
• Different optical sizing. One set lets a circle exceed the nominal grid so it looks the same size as a square; another does not.

Use one set. This is the single decision that makes an interface's icons look designed rather than assembled, and it costs nothing.

The grid and the stroke

The common convention is a 24 × 24 grid with a 20 × 20 live area, leaving 2 pixels of padding on each side, and a 2-pixel stroke. At 16 pixels the stroke usually drops to 1.5.

Two consequences worth knowing:

Optical size overrides the grid. As covered in the alignment lesson, a circle drawn to exactly 20 pixels looks smaller than a square drawn to exactly 20 pixels. Well-made sets let round shapes exceed the live area by a few per cent. If you draw your own icons, do the same, and judge by eye rather than by the guide.

Stroke weight should relate to the text it sits beside. A 1px icon next to 600-weight text looks anaemic. The icon's apparent weight should be close to the stem weight of the accompanying type, which usually means 1.5 to 2 pixels at body size and heavier beside a bold label.

Free sets worth knowing

All of these are genuinely free for commercial use, and all are permissively licensed — but check for yourself rather than taking this list on trust, because licences change.

• Lucide — a community fork of Feather, ISC licence, clean and consistent.
• Phosphor — MIT, six weights including a filled variant, unusually large.
• Material Symbols — Apache 2.0, a variable font with weight, fill and optical size axes.
• Tabler Icons — MIT, very large set on a consistent grid.
• Remix Icon — Apache 2.0, includes line and fill pairs.
• Bootstrap Icons — MIT.

One caution that catches people out: several popular sets described as free carry attribution requirements. Font Awesome's free icons are licensed under CC BY 4.0, which requires attribution. That is a mild condition and it is still a condition, and it applies to work you hand a client.

Delivering them

Inline SVG is usually correct: it can inherit currentColor, it can be styled by CSS, and it adds no network request.

<svg width="24" height="24" viewBox="0 0 24 24" fill="none"
     stroke="currentColor" stroke-width="2" aria-hidden="true">
  <path d="M5 12h14M12 5l7 7-7 7"/>
</svg>

stroke="currentColor" is the important part: the icon takes the colour of the surrounding text automatically, including in dark mode and in every state.

Icon fonts were the standard approach for years and have real problems: they fail in a specific and ugly way when the font does not load, screen readers sometimes announce the private-use character, and they cannot be multicoloured. They still work, and there is rarely a reason to choose one now.

Icons are rarely self-explanatory

This is the honest part, and it contradicts a lot of practice.

Studies of icon comprehension consistently find that recognition without a label is poor for most icons. A small set is genuinely well understood across populations — a magnifier for search, a house for home, a printer, a play triangle, a rubbish bin for delete, a plus for add. Beyond that, comprehension falls off quickly, and icons for abstract concepts such as settings, share, filter or archive are guessed rather than known, with the guesses varying by platform and by age.

The common hamburger menu is the frequently cited case: it is now widely learned, and studies through the 2010s repeatedly found that labelling it Menu improved discovery.

The design conclusion:

1. Label icons wherever there is room. Icon plus text beats either alone.
2. Where an icon must stand alone, it needs an accessible name regardless — aria-label on the button — because a screen reader announces nothing for an unlabelled glyph.
3. Decorative icons beside text get aria-hidden="true", so the label is not announced twice.
4. Do not invent an icon for an abstract concept and expect it to be understood. It will not be.