Which Icon Sets Are Available on Icônes?

Updated

Icônes (icones.js.org) is an aggregator: it does not draw its own icons but indexes many open-source icon libraries behind one search box. The sets it carries differ in style, size, and license, so the practical question is not "what is the full list" but "which set fits my project." The site's own catalog is the authoritative source — open icones.js.org and browse the collection list, since sets are added and updated over time.

What "available on Icônes" means

Icônes hosts no icon files of its own. Each set is pulled from an upstream open-source project, and the site provides:

  • A unified search across all indexed sets
  • Per-set browsing so you can see a library's full range
  • License information attached to each set
  • Copy-ready output (SVG, and framework-specific formats such as JSX/Vue components)

Because the underlying libraries are third-party, the license shown on Icônes is the license of the original project, not of Icônes itself.

How the sets differ

When choosing, compare sets on four dimensions rather than on looks alone.

Dimension Why it matters What to check
Style Mixing outline and filled icons in one UI looks inconsistent Whether the set is outline, filled, or offers both
Coverage A set may lack the specific glyph you need Search your key terms before committing
Grid & stroke Icons from different sets won't align optically Default size (commonly 24px) and stroke width
License Determines commercial and attribution obligations MIT, Apache-2.0, CC-BY, or custom terms

Style and consistency

Most indexed libraries are single-style by design. If your interface already uses one visual language, pick a set that matches it and stay within that set for a given context. Mixing sets is possible but usually requires manual adjustment of stroke weight and padding.

Coverage

Large general-purpose sets cover common UI actions (search, settings, user, arrow). Niche needs — brand logos, file types, specialized domain symbols — are often covered by dedicated sets rather than general ones. Search your actual required icons on Icônes first; a set that looks good but misses three of your glyphs will force a mix anyway.

License

This is the constraint that most often decides the choice. Licenses commonly seen across open-source icon projects include MIT and Apache-2.0 (permissive, generally require keeping the license notice) and CC-BY variants (require attribution). Some sets add their own terms. Read the license shown for the specific set on Icônes before shipping, especially for commercial products — the aggregator displays it, but the obligation comes from the upstream project.

A practical selection workflow

  1. List your required icons. Write down the specific glyphs your project needs before browsing.
  2. Search each term on icones.js.org. Note which sets return all of them.
  3. Filter by style. Keep only sets matching your UI's outline/filled convention.
  4. Check the license on the set's page against your distribution and commercial context.
  5. Export a sample in your target format and verify alignment at your actual size.
  6. Commit to one set where possible; document any second set you add and why.

Common pitfalls

  • Choosing by first impression. A set that looks clean in the browser can misalign at small sizes or in dense toolbars.
  • Ignoring the license until launch. Attribution or copyleft terms are cheapest to satisfy at the start.
  • Assuming the list is fixed. Icônes reflects upstream projects; a set can gain icons or change license over time, so re-check if you depend on it long-term.
  • Treating Icônes as the source of truth for licensing. It surfaces the license; the upstream repository is where the binding terms live.

If you need a single answer: browse the collection list on icones.js.org, shortlist by style and coverage for your specific icons, then let the license decide among the finalists.