folder-icons: a Windows 11 style icon set with an automated gallery

One style, drawn by one person

The project description is four words long, folder icons I made in Windows 11 style, and everything else in the repository follows from that. These are not recolours of an existing icon theme and not a community effort with a design system behind it. They are hand made icons in the visual language of the Windows 11 file explorer, which means the folder graphic itself is the fixed part and the interesting variation is what sits on top of it. Looking at the grid in the README makes the convention clear. There are plain glyphs for applications and languages, C, PHP, Swift, HTML, SQL, Arduino, and there are matching folder variants marked with a -folder suffix, so bash-folder, cmd-folder, apache-folder, cloudflare-folder, tailscale-folder, google-pixel2xl and the rest. The same convention covers both organisation logos and individual products, which is why the grid mixes a team name, tidwib, with a school backpack and a heart pulse icon. The audience is a desktop user who wants the Windows 11 look on Linux or macOS, and the sibling repository sameerasw/mac-icons covers the macOS side of the same idea.

PNGs, ICOs, sources and a script that writes the README

The top level of the repository shows how the work is organised, and it explains why the project is listed as Python. The PNGs directory holds the bitmap icons, the ICO directory holds the Windows icon files, and there is a PNG-to-ICO directory that presumably holds the conversion tooling. A Source directory sits alongside them, which is where the editable artwork has to live if the icons are vector based. On top of that sits generate_icons_grid.py, the script that produces the image grid embedded in the README, and the README itself marks that block with ICONS_GRID_START and ICONS_GRID_END comments so the script can find and replace it. That is the mechanism behind the gallery you see on the site, and it is the reason the README grid stays current without a human pasting hundreds of image tags. There is also a README-drives.txt file, which is presumably the list of drive icons, and a .gitmodules file, so some of the artwork or tooling comes from other repositories as submodules.

The contribution contract is precise about file pairs

The README states the rules for contributing icons in a quoted note, and it is the most useful paragraph in the file for anyone who wants to add to the set. If you are contributing icons, you have to provide both the .ico and the .png files of the same icon, in the same naming format, located in each respective directory, and the stated reason is to make the automated process of adding to the icon website easy. That is a two file rule, and it exists because the gallery and the Windows installation path consume different formats of the same artwork. The naming format matters just as much, since the grid in the README and the website both index the directory listing, so an icon whose filename does not follow the convention is an icon that does not appear in the gallery. The note closes with a thank you, and the practical upshot is that a contribution is a naming and placement exercise as much as a drawing exercise. Nothing else in the README asks for a specific canvas size or a specific colour profile, which is a small gap if you want your icon to sit consistently next to the existing ones.

Getting the icons onto a machine

The How to apply section is deliberately visual. For Windows there is a video embedded in a collapsed details block showing the icons in place, and two companion links point to conversations about Gnome and about Drive Icons, which are the two places where people discuss this kind of folder treatment on Linux. The primary route for most people is the icon website linked in the README, at sameerasw.com/icons/categories, which is described as a place to browse and download the icons, and it is categorised, which is what makes the set usable in practice, since the grid in the README is alphabetical and visual but the site is structured for looking for a specific application. For the files themselves, the README points at a directory of PNG files in the repository and notes in parentheses that it is not complete, so the website is the more reliable source if you need a particular icon. The macOS equivalent is a separate repository, sameerasw/mac-icons, and the README links to it under a question about macOS icons, which tells you the two sets are maintained separately rather than shared.

The PNG directory is explicitly incomplete

This is the limitation that will bite a user, and the README states it plainly in the same sentence that offers the PNG directory, with a parenthetical that the set is not complete. The distinction is between the website, which is the curated and current channel, and the repository directory, which is a partial copy. That means a script that wants the raw PNG files cannot assume the directory is the source of truth, and a contributor cannot assume the directory is a full inventory of what exists. The second limitation is legal rather than technical, and it is the one to raise first in any procurement conversation. There is no licence file among the top level entries, and the licence for the repository is recorded as unknown. That is not a small formality here, because icons are the entire product, and an unclear grant means the default position of all rights reserved. The artwork is a fan recreation of other companies marks, which adds a second layer of consideration that a licence file would not solve on its own. If you need the icons in a commercial product, the correct step is to ask the author what the terms are, not to infer permission from the fact that the files are public.

Releases stopped in 2023, the branch did not

The release history and the commit history tell different stories, and both matter. The recent tags are v2.91 with the description A couple more, dated 2023-08-21, v3.0 with Game icons and a couple more, dated 2023-08-30, and v3.1 with the description referencing issues ten and eleven plus more, dated 2023-09-10. So the versioning did not stop at v1, it simply stopped moving in September 2023, and the tag descriptions are informal, in the voice of a maintainer adding work in batches. The last push to the main branch was on 2026-09-12 and the repository is not archived, so the work continues in the branch even though no release has been cut since 2023. The reason is visible in the tree, since the icons that matter for users are published through the website rather than through the tags, and the tags are more like snapshots of the repository contents. For an adopter the practical consequence is that you should treat the current branch and the website as the state of the art, and the v3.1 tag as a marker rather than a current release.

Editorial conclusion

folder-icons suits a desktop user who wants the Windows 11 folder look on another platform, or a designer who needs a consistent set of app glyphs already drawn in one style, and the browsable gallery at sameerasw.com/icons/categories is the fastest way to find a specific name. It is the wrong choice for a project that needs a licence it can point at, because no licence file appears among the top level entries and the licence field is recorded as unknown, so check the terms with the author before shipping the icons in a product. Before you rely on the set, confirm the icon you need actually exists, since the README says the PNG directory is not complete, and pull the matching .ico and .png pair from the ICO and PNGs directories so the two stay in step.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sameerasw/folder-icons on GitHub