Repository navigation
Consider supporting more icon sets #11183
Description
📋 Description
Hello, thank you everyone for your work on this awesome project!
Sorry if this is a duplicate (I don't think it is), I searched the issues and discussions but didn't find other threads specific to my question (only other more specific or just different discussions)
Has the idea of including more icon sets been discussed more broadly? 🤔
simple-icons seems to only include icons for advertising the company products and services used for a project, and lack anything else beyond that. There are many interesting icon projects with generic icons that can be used for anything in a project's README! 😊
e.g. Feather includes boxes (packages, gift=donation, etc), a git branch/commit/PR icon, maybe alert-circle can be used for issues, etc.
In the meantime, i.e. shield's GitHub issue custom search in repo just puts the word query in the badge, and the flat GitHub stars badge just says stars instead of i.e. a simple general star icon (and relevant emojis, if there is one for each case, don't always look good)
I know that one can add the base64 of a custom icon, but getting manually the base64 is not the best UX 😕
To be clear, I'm not proposing to accept request for custom icons etc, just to include a couple of more icon sets that would include more expressive icons than company logos.
Thank you for hearing me out!
Activity
jNullj commentedon Jun 22, 2025
Hey @gkaklas ,
TLDR; While I appreciate your interest in improving shields, I tend towards not adding this feature.
The pros of the suggestion
I strongly agree that using named logos is drastically better UX then manually creating base64 encoded SVGs.
Also i would like to point out that having a set reduces users need to search for icons, as they is already a curated ready-to-use list if a set is used.
We currently support only Simple-Icons (SI) and custom logos - and for a good reason
As written in #10362 we currently only use simple-icons and custom logos.
Adding multiple sets would increase complexity, reduce (depending on the set) consistency and present more maintenance.
It could also present potential new issues like name collision.
It might confuse users while searching for a named logo, in what set should you search each icon? should shields present a new multi-set icon search for that? (which goes farther out of scoop for the project) We currently a very clear path when using a single icon library.
While adding another set is not the same cost as the logos we maintained in the past, some of the things discussed at #9476 are still relevant here.
Relying solely on SimpleIcons (SI) and the custom logo param streamline our process and set clear expectations for users.
This also seems to be the standard we follow, like in #10317, where we declined to expand to country/flag icons set, reinforcing the idea that Shields should not become a general-purpose icon host.
Tools and flexibility for users today
You could also see at the same issue (#10317) what options you have regarding customizing icons, but it seems you are already aware of some so i added this for others who might go into this issue or open a duplicate.
This options alone should be plenty while keeping shields maintenance manageable.
Yes, its not a UX as good as named logos, but it's also not that bad, also considering lots of badges users are devs with some understanding of how to do the manual process.
Conclusion
While there are clear benefits to use new sets, there are also new problems they would create and I think we should not add them.
I'm not strongly against such change, but at this point, I don't think its the right way to go.
Ofc, other maintainers are welcome to add their toughs if they would like to.
I doubt this will gain support as we had many discussions about logos in the past, but I will keep this open in case maintainers want to add something to the discussion.
Users who want to show support, please use emoji to rate up the issue rather then making comments like "+1" and such.
chris48s commentedon Jun 22, 2025
Related #7131
mondeja commentedon Jun 23, 2025
From a technical perspective, this can be solved with prefix identifiers for icon sets.
In the case of Simple Icons, just appending a prefix
{id}+, likesi+. In Simple Icons, there is no icons with the+character in their slugs (after simple-icons/simple-icons#13533 this is enforced in our pipeline). For backwards compatibility, you can rely on icons without prefix to resolve to Simple Icons.