Favicon advice on the web is mostly a decade out of date. The famous packages produce twenty or more files targeting browsers and devices that no longer exist, and the accompanying markup is long enough that people paste it without reading it.
The real modern set is small. Here is what each file does, and what is genuinely still required.
The files that matter
A PNG at 96 pixels covers browser tabs, bookmarks, and history on every current desktop and mobile browser. This is the icon people actually see.
An Apple touch icon at 180 pixels is what iOS uses when someone adds your site to their home screen. It is the one icon that gets displayed large, so it is worth checking rather than assuming.
Two manifest icons at 192 and 512 pixels, referenced from a web app manifest, cover Android home screens and install prompts. The 512 version is also what appears on a splash screen.
And favicon.ico, which is nearly obsolete and still worth including for one specific reason covered below.
Filum produces exactly that set — seven files, plus the markup, plus the manifest — rather than padding it out with sizes nothing has requested since Windows 8 tiles.
Why favicon.ico still earns its place
Modern browsers read the icon links from your HTML, so in normal browsing the old .ico file is never requested. There is one case where it still is: when a browser displays something that is not an HTML page from your domain — a PDF, most commonly — there is no markup to read, so it asks for /favicon.ico directly and shows whatever comes back. Without the file, that tab has a blank icon.
It costs almost nothing to include, so Filum builds it, containing 16, 32 and 48 pixel versions. It builds it the compatible way as well: the three sizes are stored as plain uncompressed bitmaps, the format every reader has understood since the 1990s, rather than the newer compressed form that would save around 12 KB on a file each visitor downloads once. Compatibility is the entire reason this file still exists; optimising it at the cost of that would be an odd trade.
Two ways a correct favicon package still looks broken
The first is transparency on iOS. Apple's home screen does not leave transparent areas of an icon clear — it fills them with black. A logo designed to sit on a light page turns into a dark square on a phone, and because it only appears when someone adds the site to their home screen, it is easy to ship and never notice. Filum detects transparency and lets you pick a background colour for the Apple icon specifically, leaving the other icons transparent.
The second is the markup. The files on their own do nothing; the browser has to be told where they are. Every favicon package includes markup and most people paste it without checking that it matches the files they actually received. Filum shows the markup on screen and includes it as a text file, and only links a favicon.svg when there genuinely is one — so nothing in your HTML points at a file that does not exist.
Non-square, too small, and what should not happen to your logo
If your source is not square, the honest treatment is transparent padding and centring. Cropping to square is the other option and it is worse: it silently removes part of your logo, and you cannot see what went missing. Filum pads.
If the source is smaller than a target size it has to be enlarged, and enlarging cannot invent detail. Filum tells you which sizes were enlarged and by how much, and says plainly when a source below 96 pixels is simply too small to make a sharp favicon. A square image of 512 pixels or more needs none of this.
One more thing worth knowing: generated PNGs commonly carry metadata identifying the tool that made them. Filum's do not — the PNGs contain image data and nothing else, no software tag, no timestamp, no author field. And because everything is generated inside your browser, the logo itself is never uploaded, which matters when the logo is the first asset a company has and frequently unreleased at the moment someone is setting up the site.