Fill icons

[mittalyashu]

This discussion is about creating fill icons.

Here's the creation of home icon with fill mode.

Preview

<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> <path d="M11.3861 1.21065C11.7472 0.929784 12.2528 0.929784 12.6139 1.21065L21.6139 8.21065C21.8575 8.4001 22 8.69141 22 9V20C22 20.7957 21.6839 21.5587 21.1213 22.1213C20.5587 22.6839 19.7957 23 19 23H16C15.4477 23 15 22.5523 15 22V14C15 13.4477 14.5523 13 14 13H10C9.44772 13 9 13.4477 9 14V22C9 22.5523 8.55228 23 8 23H5C4.20435 23 3.44129 22.6839 2.87868 22.1213C2.31607 21.5587 2 20.7957 2 20V9C2 8.69141 2.14247 8.4001 2.38606 8.21065L11.3861 1.21065Z" fill="black"/> </svg>

The above svg code is not optimised

[alensiljak]

It would be great if something like this could be achieved with an attribute (i.e. fill). There already is the fill attribute, actually, that can be used. For example: <Home fill="red"> but the results are not always what one would expect. :)

Related to #826 in a potential attribute that would fill an existing icon. Not sure that this would work for all, but inside a bordered container, perhaps it could invert the icon. i.e. x circle fill

[edwardalex]

Where can I get icons for free?

[moeenio]

in this repo

[edwardalex]

Thanks

[karsa-mistmere]

Closed #893 #407 in favour of keeping all discussions related to filled icons here.

[CarlosVergikosk]

I would like to bump this, fill icons are very useful.

[danielbayley]

We could construct certain icons in a slightly different way, and do something like—for example with shield-half—this:

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
>
  <path class="lucide-fill" d="M12 22s-8-4-8-10V5l8-3" />
  <path class="lucide-hide" d="M12 22V2" />
  <path d="m12 2 8 3v7c0 6-8 10-8 10" />
</svg>

which looks exactly the same, by default:

Then, optionally just have something like this in your CSS, to activate the fill version:

.lucide-fill { fill: currentColor }
.lucide-hide { stroke: none }

resulting in:

Some kind of svgo optimisation build step could even easily be added to strip out the classes, if desired.

What do you guys think? cc: @ericfennis @jguddas @karsa-mistmere

[danielbayley]

Preview

@mittalyashu You would want to add the fill as well as retain the stroke, to avoid it looking like shit…

[aaronmahlke]

This is great! My only problem with using lucide-icons at the moment is the lack of filled icons.
I even began playing around with filled icons recently because I thought of forking and creating a filled icon version myself. However I would love the main repo to adapt this instead.

My Thoughts

In my test i noticed a few things. Many icons work quite well out of the box, some need some extra attention.

Here is a preview of what I have so far:
(none of those are optimized in any way)

Icons with open ends

Especially icons that have open ends would need some adjustment. Here is my attempt at solving some of those open end icons:
I decided on using a circle as a cutout to reveal more of the other shape.

Icons with no fill possible

Some icons like arrows and similar stroke icons simply don't have a good way to have a filled version. In those cases I would leave all them the same but outline them (convert the strokes to an outline).
Outlining leads to another issue, but more on that later...

Scaling Icons

Scaling with stroke icons is different than scaling with filled icons.
Outline strokes (in this example the lightning) scales as well as the rest of the icon. This does not happen with the original line icons, the lightning stroke width stays the same width for all icon sizes. This would be something we would have to keep in mind. One possible solution could be to adjust for multiple sizes (in my case we are looking at 24px, 16px and 12px)

---

Anyway those are my first thoughts around this topic and i would love to actively push this further.

[karsa-mistmere]

One thing I feel pretty strongly about is that filled icons should not be a full separate Lucide set, but instead a group of icons that are pretty much an integral part of the core package(s).

Firstly, this leaves plenty of room for our filled icon set to grow without the need for forcibly having to add and maintain multiple different variants of the same icon.

And more importantly: not all icons need a filled variant to begin with, in fact a lot of our icons are based on lines that cannot and need not be filled.

[aaronmahlke]

Yes I definitely agree. However what do you think about consistency between using filled icons and also mixing them with stroke icons?

I am afraid that the scaling could become an issue when using both next to each other.
Let's say we use two icons in 12px size: one icon is filled, let's take my cloud-lightning icon from my example above and pair it with an unchanged arrow-right icon (also scaled down to 12px). The problem I see here is you get vastly different stroke widths for filled icons that also include some sort of stroke. However if we would have an outlined version of the stroke icons they would scale the same way as the filled icons:

Here the stroke from the lightning is not consistent with the stroke from the arrow

Here the stroke from the lightning is consistent with the stroke from the arrow

I do think this could also be done programmatically. Icons that don't need to be filled, could automatically be outlined for the filled version.

Another issue I see if we wouldn't be doing this, is the problem on how to address the icons in code. Let's say we wan't to only use "filled" icons in our project and therefore use the fill attribute to change color of icons. Now we switch the icon to be an arrow for example (which does not have a filled version) and we suddenly need to change the stroke instead.

[tryoxiss]

Handling the diffrent stroke widths are certinly a challange. In the seccond example, you say strokes are equal (which they likely are), but notably don't feel equal since they are diffrent visual weight. One way to handle it may be to use stroke for those stroke like elements, but that has its own host of problems (notably having it scale disproportianly, possibly having the lightning intercept the cloud).

As for code, you could make them proxy each other. For example if you set the fill attribute and request a stroke only version due to it being only lines, the request will return the stroke version.

EDIT: I see three additional categories of icon that need attention, beyond the ones with gaps

Slashed/-off Icons

For example message-square-off. I think these are a pretty easy fix, as we just need to fill both sides and ensure a clean gap between the halves. This would still take some manual work, though.

Solid-shape with stuff icons

Icons that are mostly a solid shape that can be easilly filled, but need to have bits cut out. For example message-circle-x would be as simple as filling the message bubble and using the existing "x" shape as a cutout.

Special Cases

EDIT: I see in your demo you had many of these solved. I am keeping this section here as despite working well and having simple solutions, they still require additional thought and rules.

While most icons fall into either the two categories mittalyashu brought up or the additional two I brought up, a few will require special attention. For example newspaper is mostly just a fill-and-cut situation, but the back page should probably remain outlined. Another example would be the book and possibly archive icons which are the same deal. Additionally icons like gem may require special attention.

This is a vast minority of the icons, and most likely have simple solutions, but would still require additional discussion to agree on rules for edge-cases like this.

[zoharma]

It would be great to have these at least for icons such as circle-check and circle-x and the other complete circles and squares.
At the moment there's a need to target the internal path and fill to make it happen, essentially creating a subset of icons within the application.

(update with new icon names and links)

[mblode]

What if Lucide used Tabler's filled icons as a starting point. Tabler seems to use the same fundamental rules as Feather/Lucide. https://github.com/tabler/tabler-icons/tree/main/icons/filled

https://tabler.io/icons

I'm curious why there's never been a discussion of lucide and tabler merging the icon libraries with the substantial overlap

[jamiemlaw]

I've been having a play-around with how certain icons could be filled, including the edge-case ideas mentioned above:

https://codepen.io/jamiemlaw/pen/WNqwQpG/782fa485aa0c544b06557d4e0aac47c9

It uses the same tactic as @karsa-mistmere's https://jsfiddle.net/cgd9a3h0/1/ by filling in parts of the icon and then using a mask to invert the strokes. I really like that as a concept. However, I'm not using classes, but instead hardcoding the fills and strokes, and treating the filled icons as separate entities to their outline counterparts.

For icons like calendar-clock and cloud-drizzle I used an extra-wide stroke to carve out space for the detail on top, which feels like quite a flexible solution.

For details like the clock on the calendar or the heart on the book, I considered making these filled too, but I kinda prefer them as strokes.

[tryoxiss]

These look great, although the gem and raincloud look a bit funky in perhaps not a good way.

[hexxt-git]

how can i fill an icon with a tailwind variable?

[tryoxiss]

This is a dicussion about adding filled versions of the icons. For some icons, you could use the fill-current tailwind class but that will break many icons.