Favicon and App Icon Sizes: Which File Is for Which Platform

Six Sizes Because Six Pieces of Software Ask

Each file in the pack has a customer, and the customers do not read each other's files. A browser tab asks for one size, a Windows shortcut for another, an iPhone's Home Screen for a third, and an Android install prompt reads the manifest rather than any link tag. Producing one 512-pixel PNG and hoping every surface scales it down is how a logo arrives with cropped corners in one place and unreadable mush in another.

The generator on this site emits the six that cover almost every real request, under the filenames the bundled HTML snippet references. Renaming them is the most common way an icon pack silently stops working, because the link tags point at the names, not at your preference.

• favicon.ico is added too, carrying PNG-compressed frames at 16, 32 and 48 pixels in one file.
• The ZIP also contains site.webmanifest and favicon-html-code.html, so the HTML and the manifest ship with the images rather than being reconstructed later.
• Sources are expected to be square: every frame is a square canvas and the source is drawn to fill it, so a wide logo loses its edges at every size.

Note: The upload box asks for at least 256 x 256. That floor exists for the 512-pixel frame, not the 16-pixel one: a small source is inflated to the large sizes and arrives soft.

What a .ico File Actually Contains

favicon.ico is a container rather than a single image. Its first six bytes are a header: a reserved field that must be zero, a type field where 1 means icon, and a count of the images inside. That is followed by one directory entry per embedded image and then the image data itself. The generator writes three frames, at 16, 32 and 48 pixels, encoded as PNG inside the ICO, which is why the same file renders correctly in a browser tab and in a Windows file list.

There is a reason the format still earns its place after two decades: a browser that finds no icon declaration at all requests /favicon.ico from the domain root, and that request is what fills the 404 lines in the logs of a site that shipped only PNGs. One multi-frame ICO answers it with a size that fits, instead of leaving every consumer to scale a 512-pixel artwork down to a 16-pixel tab.

The format is also small on purpose. Each dimension is stored in a single byte in the directory entry, with a 256-pixel frame written as zero, which is the largest size an ICO frame can declare. Anything bigger belongs in the manifest as a PNG, and that is exactly how the pack is divided.

Draw for Sixteen Pixels First

Every frame in the pack is a scale-down of the same source, produced with the browser's own canvas: high-quality image smoothing, a cleared rectangle so transparency survives, and the source drawn to fill each square. No frame is hand-tuned, which is good for consistency and unforgiving about detail. The glyph that reads at 16 pixels is the only glyph that will read at 16 pixels, so design from the small end upward.

In practice that means one bold shape or a two-letter monogram, thick strokes, no serifs, and generous margins. A wordmark that is beautiful at 512 becomes grey texture at 16. Contrast matters more than colour here: browser chrome can be light or dark, and a low-contrast mark disappears into whichever one it lands on. Because the canvas is cleared rather than filled, a PNG source keeps its alpha channel; a JPEG source has no alpha to keep and arrives with whatever background it was saved with.

• Squint test that actually counts: look at the real tab at real size, not the preview grid.
• Two letters maximum, or one geometric shape. Nothing with a hairline stroke survives 16 pixels.
• Check the mark against both a light and a dark browser chrome before committing to the palette.
• A transparent background is correct for tabs; for an installable app icon, a filled background reads better once a launcher applies its own mask.

The Generated Manifest Needs Two Edits

The site.webmanifest inside the ZIP is a working skeleton, not a finished file. It ships with the name field set to My Website, short_name set to Website, both theme_color and background_color at #ffffff, and display set to standalone. Those strings are what a user sees under the icon on an Android Home Screen and during the splash screen after an install, so the two name fields and the two colours are the edits to make before uploading it.

The icons array points at /android-chrome-192x192.png and /android-chrome-512x512.png, each entry declaring src, sizes and type. The manifest format allows more per entry than that, including several sizes in one sizes string and a purpose field that tells the platform how the artwork should be treated. The skeleton declares neither, and that is the honest gap in the pack: it contains no maskable icon.

A maskable icon is the same artwork composed so it survives a launcher that crops your icon into a circle or a squircle. The platform applies its own mask over the file, so the mark has to sit inside a safe central area on a filled background; a normal icon pushed through that mask gets its corners cut away or ends up letterboxed inside a coloured square. If the install experience matters to you, render a second 512-pixel file with the mark smaller and the background extended, then add a second entry to the manifest declaring that purpose. This site keeps its own maskable file for precisely that reason.

Note: Check the field names against the manifest specification rather than trusting memory: the icons members are documented on MDN, and a mistyped sizes value is invisible until somebody installs your site.

Where the Files Go, and What Points at Them

1. Root, not a folder — Put favicon.ico and the PNGs at the site root. The generated HTML references /favicon-32x32.png with a leading slash, so a folder changes every line or breaks every link.
2. Paste the five lines — The pack carries favicon-html-code.html and the tool has a copy button for the same snippet: an icon link for the .ico, one for each of the 32 and 16 pixel PNGs with its sizes attribute, the apple-touch-icon link at 180, and the manifest link. They belong in the head of every page, or in the layout that renders the head.
3. Upload the manifest after editing it — site.webmanifest goes at the root too, referenced by the manifest link tag. Change the two name fields and the two colours first, and confirm the icon paths inside it match the filenames you actually uploaded.
4. Then break the cache — Favicons are cached hard and separately from the rest of the page. Reload without the cache, and check a window in a different browser profile before concluding the icon is broken.
5. Verify on the surfaces that matter — Look at a tab, a bookmark entry, a phone Home Screen shortcut and, if the site is installable, the install prompt. Those are four different renderers, and only the first one is easy to notice when it is wrong.

Limits Worth Knowing Before You Ship the Pack

The generator rasterises rather than redesigns. It scales one artwork to six squares; it does not produce a simplified small-size variant, a maskable composition or an adaptive icon with foreground and background layers, all of which are separate design jobs. If a mark genuinely needs a different drawing at 16 pixels, that second artwork has to be drawn by a person and fed in as its own source.

It also trusts the source's aspect ratio and colour mode. A rectangular logo is stretched into a square canvas, a CMYK JPEG may render with shifted colour depending on the browser decoding it, and a very large artwork is decoded into memory like any other image, so a 4,000-pixel export is wasted effort when 512 is the largest frame produced.

Finally, this is an asset generator, not a brand audit. It will happily produce six pixel-perfect files of an icon nobody can read. The check that matters happens after the download: open the tab, squint, and decide whether the mark survived.