Icon sets compared

ICON OOP bundles seven freely licensed collections. They are not interchangeable. Each was drawn to different rules by different people for different purposes, and mixing them is the most common cause of an interface that looks subtly wrong.

The comparison at a glance

Note the licence column. Six of the seven need no attribution. Emoji, under CC-BY 4.0, does. That single difference is the one people miss.

The four UI sets, in detail

Lucide

Good at: consistency. It is drawn to a written specification, so an icon added last month sits correctly beside one from 2020. Restrained, geometric, and it disappears into an interface rather than decorating it.

Bad at: coverage of niche concepts, and filled variants. If your product has a specialist domain you will hit gaps.

Choose it when you want the icon question settled and forgotten about.

Tabler

Good at: having the icon. Over 5,000 of them, including matched outline and filled pairs, which makes selected and unselected states trivial. Shares Lucide's 24 grid and 2px stroke.

Bad at: restraint. With this many options, two developers will pick two different icons for the same concept, and six months later you have three settings icons.

Choose it when you are building something domain-heavy: clinical, logistics, finance, internal tooling.

Phosphor

Good at: flexibility. Six weights per icon means icon weight becomes a design token alongside type weight, and the React package lets you set it globally.

Bad at: mixing with anything else, because of the 256 grid. And it gives you a decision to make on every icon, which small teams may not want.

Choose it when you are building a design system properly rather than picking icons for a project.

Material Symbols

Good at: the variable axes, particularly optical size, which changes how much detail an icon carries at different display sizes. Nothing else free does this. And fill as a continuous axis means you can animate it.

Bad at: looking like anything other than a Google product. That is a feature if you are building an Android app and a liability if you are building a distinctive brand.

Choose it when you are inside Google's design language or need runtime axis control.

The three logo and emoji sets

Brand logos come from two CC0 collections: monochrome single-path marks with official brand hex codes as metadata, and full-colour logos including gradients. Use monochrome inside your own design system, full colour when the logo is the subject.

Devicon covers programming languages, frameworks, databases and dev tooling, in original, plain, line and wordmark variants. It exists because general logo sets do not cover PostgreSQL, Terraform or Kubernetes well.

Emoji from Twemoji, useful when you need every user to see the same picture rather than their own platform's rendering. The CC-BY attribution requirement applies.

All three are logo or artwork sets rather than UI icon sets, so the one-set rule does not apply to them. Mixing brand logos with your UI icon set is normal and expected.

How to actually choose

Skip the feature comparison and run this instead. It takes fifteen minutes and gives you a better answer than any table.

1. List your ten hardest icons. Not "home" and "settings". The ones specific to your product: whatever concept your domain has that a general icon set might not.
2. Search for all ten in each candidate set. The set that has eight or nine of them without compromise is your answer, and this usually decides it outright.
3. Put the found icons in a row at your real display size. 16 or 20 or 24 pixels, not 64. Check they read clearly and carry equal weight.
4. Check them against your typeface. Rounded icons want humanist type. Sharp icons want tighter grotesques. Mismatch here is subtle and permanent.
5. Check the filled or active state you will need. If your navigation has selected states, confirm the set can express them.

On mixing sets

The standard advice is never mix, and the standard advice is right, with a caveat worth knowing.

Mixing fails because sets differ on three axes simultaneously: stroke weight, corner radius, and level of detail. Any one difference is survivable. All three at once produces an interface where icons look like they came from different products, which they did.

The caveat: Lucide and Tabler mix better than most, because both use a 24 grid with a 2px rounded stroke. If you are genuinely stuck, use one as your base and take only the missing icons from the other, then check them side by side at your real size. This is a compromise, not a strategy.

What never works is taking whichever icon looks best for each individual search. That is how a project ends up with icons from five libraries and nobody able to say why the interface feels off.

Licences side by side

"Notice with source only" means you keep the licence file if you redistribute the icon files themselves. It does not mean a credit on your website. The full explanation is in icon licensing, and brand marks carry separate trademark considerations regardless of file licence.

Switching sets later

It is more painful than choosing well, and less painful than people fear. What makes it manageable is having a written icon inventory: a list of every concept in your product and the icon name you use for it. With that, switching is a mapping exercise. Without it, it is an audit of your entire codebase first.

If you are early enough to still be deciding, write the inventory now regardless of which set you pick. It is the single highest-value thing you can do about icons, and it takes ten minutes.

Frequently asked questions