Usually because they came from three different places. Icon sets are drawn on different grids with different stroke weights and different corner shapes. Mix two of them on one page and the eye notices the mismatch even when nobody can name what is off. Consistency matters more than the individual drawings.
We see this constantly on sites we inherit. A checkout uses one set, the feature grid uses another, and somebody dropped a third one into the footer because it was the only cart icon they could find that day.
None of those choices was wrong on its own. Together they make a site look assembled rather than designed.
A good icon is instantly readable at its real size, matches the weight of the text beside it, and means one thing. If people have to hover to work out what it does, it has failed. The best icons on the web are boring on purpose, because familiarity is the whole point.
Readability at size is the test people skip. An icon that looks lovely at 200 pixels in Figma can turn into grey mush at 16 pixels in a nav bar. We check every icon at its shipping size before it gets approved.
Weight matching is the second test. If your body text is a light weight and your icons are drawn with heavy 3 pixel strokes, the icons shout over the words. Stroke width should feel like it belongs to the same family as the type.
Meaning is the third. A magnifying glass means search. A house means home. Reusing a magnifying glass for zoom on the same site that uses it for search is the kind of small confusion that adds up.
Use one set for everything, and treat that as close to a rule. A single set gives you a shared grid, a shared stroke weight, and a shared visual language for free. Mixing sets is the fastest way to make a professional site look like a template someone edited in a hurry.
The pushback we hear is that no set has every icon. That is true, and it is solvable. When a set is missing something, we draw the missing icon on the same grid with the same stroke weight rather than importing a stranger.
Drawing one icon in the house style takes an hour. Living with a mismatched set for three years costs more than that in quiet credibility.
Icons belong in your design system alongside colour and type for exactly this reason. We covered how to set that up in our guide to building a design system for a website.
Use SVG. Icon fonts were a clever workaround for a problem the web solved years ago, and they carry real costs. They render as text, so they inherit font smoothing, they can fail into unreadable boxes if the font does not load, and screen readers sometimes announce the private use character instead of nothing.
SVG avoids all of that. It is real markup, it scales without blurring, it can be styled with CSS, and you can animate individual paths if you want to.
Inline SVG is our default for anything that needs styling or animation. For a large set that never changes colour, an SVG sprite keeps the markup lighter and still lets you cache the file.
The one place icon fonts still turn up is inside an old theme somebody does not want to touch. That is a legitimate reason to leave them alone. It is not a reason to start a new project on them.
The icon can be small, but the tappable area cannot. WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), is a Level AA requirement that the target for pointer inputs is at least 24 by 24 CSS pixels. The stricter Success Criterion 2.5.5, Target Size (Enhanced), asks for at least 44 by 44 CSS pixels at Level AAA.
The distinction people miss is that the target is the clickable box, not the drawing. A 16 pixel icon inside a 44 pixel button is fine. A 16 pixel icon with 16 pixels of clickable area is not.
The W3C lists exceptions to the minimum criterion, including a spacing exception where a 24 pixel circle centred on each target does not intersect other targets, an exception for equivalent controls elsewhere on the page, and one for targets inline in a sentence.
We build to the 44 pixel figure on anything a thumb has to hit, because phone users are not aiming carefully while walking. Meeting the higher bar costs padding, not budget.
It comes down to one question: does this icon carry meaning, or is it decoration next to text that already says the same thing? If it carries meaning on its own, it needs an accessible name. If it sits beside a visible label, it should be hidden from assistive technology so nobody hears the word twice.
An icon only button is the common failure. A bare cart or menu icon with no text needs an aria-label so a screen reader announces something useful instead of the word button on its own.
The decorative case is the opposite fix. An icon sitting next to the words Download report should carry aria-hidden set to true, because otherwise the user hears the icon announced and then the label.
We test these with NVDA on Windows and VoiceOver on macOS rather than trusting a checker. Automated tools are good at finding a missing label and bad at telling you the label is unhelpful. The wider testing routine sits in our guide to making a website WCAG accessible.
Sometimes, and less often than designers hope. Icons work brilliantly when they are conventional and paired with words. They work poorly when they are asked to replace words, because an abstract shape means whatever the viewer already believes it means.
The honest use of an icon is as a landmark rather than an explanation. It helps someone find the row they want again after scrolling, and it gives the eye somewhere to rest in a dense layout.
We are sceptical of feature grids where every card gets an icon by default. Half the time those icons are decoration hired to fill space, and the page would read faster with better headings instead.
Our test is simple. Cover the icon and read the page. If nothing is lost, the icon is decoration, which is fine as long as you are honest that it is not doing work.
We start with Lucide for most projects. It is an open source library that provides more than 1,600 vector SVG files and is released under the ISC License, so there is nothing to negotiate before you ship a client site. Its stroke style also sits comfortably next to most sans serif type.
Heroicons is the other one we use often. It is made by the team behind Tailwind CSS, includes 316 icons, and is distributed under an MIT license. It ships outline, solid, mini and micro variants, with the outline set drawn at 24 by 24 with a 1.5 pixel stroke.
That variant range is more useful than it sounds. Having a micro version drawn for small sizes beats scaling a 24 pixel icon down and hoping the strokes survive.
Other sets worth knowing are Phosphor Icons, Feather, Font Awesome, and Google's Material Symbols. Whichever you pick, read the licence before the client sees it, because discovering an attribution requirement after launch is a bad afternoon.
Less than most things, but it is easy to make it worse than it needs to be. Loading an entire icon library to use nine icons ships hundreds of unused paths. Inlining only the icons you use keeps the payload tiny, since a simple SVG icon is often smaller than a line of CSS.
Exported SVGs are usually messier than they need to be. Design tools add editor metadata, empty groups, and absurdly precise decimals. Running files through SVGO strips that out without changing how they look.
The other trap is using a raster image where a vector belongs. A PNG icon has to be exported at several densities and still blurs on a screen you did not plan for. We covered the wider picture in our guide to optimising images for web performance.
Open your site and count how many icon sets are on it. If the answer is more than one, pick the set that covers most of your needs and standardise on it. Then check that every icon only button has a real accessible name and a target at least 24 by 24 CSS pixels.
Those two passes take an afternoon and they fix the majority of icon problems we find on client sites. Everything else is refinement.
If you want help choosing a set that fits your brand, or you want the icon work folded into a proper design system, we are happy to talk it through. Reach us at phoenix.studio and we will take a look at what you have.
Tell us where you want to go. We'll tell you how we'd get you there.