Favicon packages.

What is in the ZIP, and whose side this guide takes

Open the ZIP the favicon generator downloads and you find more than one icon: a multi-size favicon.ico, a set of PNG favicons, an Apple touch icon, a pair of Android icons with a maskable twin for each, a site.webmanifest, a favicon-snippet.html and a README.txt. All of it is drawn from one design on canvases inside your browser tab, and a logo you choose is read by the browser’s own file reader; the tool’s notice reports the file as loaded locally. Nothing was uploaded.

The tool page explains the mechanism: the render function, the padding arithmetic, the ICO builder’s refusals. This guide takes the installer’s seat — what each file is for, what each line of the three text files says, what to check once the files are in place, and which questions the package cannot answer. Every byte figure and example string below is computed at build time from the ICO builder or emitted by the engine’s shared slug rule; the render sizes, padding bounds and ratios are not exported, so this guide restates them in words from the render function, not as figures. The date above is the month that reading was done. The methodology sets these rules beside every other tool’s.

The files, grouped by job

The design is seven choices — a site name, an optional logo or image, a background colour, a monogram colour, a padding percentage, a shape and a transparent-background switch — and every image in the ZIP is that design rendered on a square canvas of a different side, while the three text files describe where those renders live and how to put them in place. Grouped by job:

• favicon.ico — one container holding four of the smallest renders as PNG entries. It is the only file in the package whose contents are several images.
• PNG favicons — the same four small renders as separate files, each named favicon- followed by its pixel size.
• apple-touch-icon.png— one render at the Apple touch size, and the only PNG whose file name carries no size. Its sizes string appears in the snippet’s link instead.
• Android icons — two renders at the two Android sizes, named android-chrome- followed by the size, and listed in the manifest with purpose any.
• Maskable Android icons — the same two sizes rendered again under the maskable rule, with maskable in the file name, and listed in the manifest with purpose maskable.
• The three text files — site.webmanifest says which install icons exist, favicon-snippet.html is what to paste into the page head, and README.txt says how to install.

The README’s Included list names each group with its pixel sizes. It is the one file in the package where every size appears in digits, which is why this guide points there rather than restating them.

Installing: the README's four steps, read closely

README.txt opens with a title line and then four numbered steps. Step one: copy the icon files and site.webmanifest to the public root of your website. The root is not a stylistic preference. Every href the snippet writes and every src the manifest writes begins with a slash, so each file is addressed from the root of the domain and the paths resolve only when the files sit there; putting them anywhere else means editing every path by hand, and the engine writes no relative-path variant.

Step two: paste the contents of favicon-snippet.html inside the <head> of each page. The snippet is plain markup with no script and no wrapping element, so it drops into a template or a static page alike. It declares a different set of files from the manifest; the one value both carry is the theme colour.

Step three: clear browser and CDN caches after replacing an older favicon. The package gives this step a reason of its own: the file names are fixed so the snippet keeps working unchanged, which also means a new favicon.ico lands at exactly the path the old one occupied.

Step four: test the site in a browser tab and on a mobile home screen — two of the places the tool’s own copy names when it says where a favicon appears. The README then closes with the Included list.

The snippet, line by line

favicon-snippet.html is six lines, each a complete tag, joined with line breaks and nothing else. In the order the engine writes them:

1. An icon link to /favicon.ico with sizes="any". This is the one tag that points at the multi-size container rather than at a single PNG, and the engine declares it for any size rather than listing the four sizes packed inside.
2. An icon link with type image/png and the sizes string of the second-smallest render, pointing at the PNG favicon whose name carries that size.
3. The same for the smallest render. The engine writes the larger PNG link before the smaller one, so the two PNG lines are not in ascending order; both follow the ICO line.
4. An apple-touch-icon link with its sizes string, pointing at /apple-touch-icon.png — the one place outside the README where the Apple touch size is written, since the file name does not carry it.
5. A manifest link to /site.webmanifest.
6. A theme-colormeta whose content is the design’s background colour, written as picked.

Three things the snippet does not contain: links to the two larger PNG favicons, which sit in the ZIP beside the ICO but are declared by neither the snippet nor the manifest, so only the ICO carries them to the browser; links to the Android or maskable icons, which the manifest declares; and any size the engine did not render. Every hrefbegins with a slash, which is the reason behind the README’s first step.

The manifest, field by field

site.webmanifest is JSON the engine writes from the design and pretty-prints with two-space indentation. name is the site name with surrounding whitespace trimmed, or the word Website when the field is empty. short_nameis the opening run of that name’s characters cut at a fixed length the engine keeps inside the render module: a long site name is truncated there with no ellipsis, a short one is carried whole. icons is a list of four entries in a fixed order — the two Android PNGs with purpose any, smaller then larger, followed by the two maskable PNGs with purpose maskable, smaller then larger. Each entry carries src, a root-relative path to the file; sizes, the pixel size written as width by height; and type, always image/png.

theme_color and background_color are both set to the background colour, so a transparent design still declares a colour here; the switch affects the standard renders, not the manifest. display is standalone and start_url is /, the site root. The manifest does not list the ICO, the small PNG favicons or the Apple touch icon; the snippet declares the ICO, the two smallest PNGs and the Apple touch icon, while the other two small PNGs are shipped in the ZIP as files of their own but are declared by neither file and reach the browser only through the ICO.

Standard and maskable files, side by side

Open a standard render and a maskable render of the same size and the differences are the engine’s rules made visible. The standard file is clipped to the chosen shape — a circle, a plain square, or a rounded square whose corner radius is a fifth of the side — and, with the transparent switch on, is clear outside the mark. The maskable file has no clip: the engine fills the entire square with the background colour and ignores the switch, so it is solid to the edge whatever the design says.

The mark inside is placed the same way in both. An image is scaled until its longer side fits the padded box, proportions kept, and set in the middle; with no image, the mark is the upper-cased first character of the trimmed site name in a heavy weight of the Arial / sans-serif stack, sized at roughly two thirds of that box and set in the middle with a slight downward offset, and an empty name yields the letter P. Colour is applied as picked, with no contrast check in this engine; the promo design basics guide covers contrast where the Studio does measure it.

Padding is where the two files diverge most. The slider’s percentage is clamped to the engine’s range — nothing below zero, nothing above the slider’s top — and turned into a fraction of the side; for the maskable pair the engine raises that fraction to a floor of a fifth of the side whenever the slider asks for less, so below the floor the maskable files are visibly more padded than their standard twins and above it every file matches. The engine renders the maskable pair as a solid, padded square because a platform mask may take the edge — the tool’s own “leave breathing room” advice — rather than because of any documented mask shape; this guide carries no figure for what any platform masks. The tool page works through the pixel arithmetic.

favicon.ico from the outside

favicon.icois the one file whose size cannot be read off a single render, because it is four renders behind a directory. The engine’s ICO builder writes a header, one directory record per entry, and then each entry’s PNG bytes unchanged, in the order given. Building two one-byte-payload ICOs here and subtracting their payloads measures the header at 6 bytes and each record at 16 bytes, so the four-entry directory the package writes is 70 bytes, and favicon.ico is exactly that much larger than the four PNG favicons beside it added together.

That the PNG bytes are copied rather than re-encoded is checked at build time too: a fictional four-entry ICO is built here from stand-in payloads of recognisable filler — payloads of 13, 29, 41 and 53 bytes at declared sizes of 24, 40, 56 and 72 pixels, 136bytes in all — and each payload is read back byte for byte at the offset its record declares. The record also stores the entry’s width and height in single bytes, its colour-plane count, its bit depth and its byte length. None of this is something an installer edits. It is why the ICO can be served as one file and still carry four sizes, and why nothing inside it is a different drawing from the PNG favicons next to it.

The ZIP's name, and what it does not change

The ZIP takes its name from the site name by way of the slug rule the whole site shares. That rule lower-cases the text, drops the whitespace at its ends, turns each run of characters that are not a–z or 0–9 into a single hyphen and strips a hyphen left at either end; the engine then adds -favicon-package.zip. The fictional Northwind Tide Tables downloads as northwind-tide-tables-favicon-package.zip; typed in mixed capitals with spaces either side, as NORTHWIND tide TABLES, it downloads as the same northwind-tide-tables-favicon-package.zip, because case and edge whitespace never reach the slug; Café Nº 7!, with accents and symbols, slugs to caf-n-7; and an empty name takes the rule’s fallback, promo.

Nothing inside the ZIP is named after the site. Each file keeps the fixed name the snippet and the manifest expect, so renaming the ZIP, or receiving one named for a different site, changes nothing about the install: the files are copied as they are. Inside the package the site name surfaces in two places only — the manifest’s name and short_name, and the monogram’s first character when no image is chosen.

Troubleshooting from the package's side

• The icon in the tab is still the old one.The README’s third step: the file names are fixed, so the new favicon.ico occupies the old path. Clear browser and CDN caches.
• The paths resolve to nothing. Every href and srcis root-relative. The files belong at the public root — the README’s first step — or every path must be edited by hand.
• The maskable icons are plain squares although the design is a transparent circle. By design: the maskable rule drops the shape clip and the switch and fills the square. The standard files carry the shape and the transparency.
• The manifest’s name reads Website. The name field was empty when the package was downloaded; the engine trims the name and falls back to that word, as it falls back to the letter P for the monogram and to promo for the ZIP.
• The mark is faint against its background. No contrast measurement runs in this engine, so a pale-on-pale pair is rendered as chosen. Re-pick the colours in the tool and download again; nothing in the package adjusts colour.
• The files look different from the preview strip. The strip never showed the files: it is a single large render shrunk by the browser to several frame sizes, while the download draws every icon on a canvas of its own side. Judge the files.
• The Apple touch icon has no size in its name.By design. Its size is written in the snippet’s link and in the README’s Included list.

Where the engine stops, and what this guide does not say

The tool takes JPG, PNG, WebP and SVG sources up to a fixed size and refuses other files with a notice. An SVG is decoded by the browser as an image and drawn at each size like a bitmap; the engine ships no SVG icon and reads none of the markup. It does not remove a background — the background remover is a separate tool — or change the source’s format, which the image converter does. And the package is a download, not a deployment: no file is placed on your server for you, which is what the README’s four steps are for.

No platform figure appears here. The site’s specs registry, which dates every platform figure the site states, has no entry for icon sizes, manifests or home-screen behaviour, so this guide does not say which size any browser or platform selects, what shape a mask takes, or whether a given file is required. Install the whole set, as the tool’s copy advises, and check any platform’s requirements against its own documentation before a launch. The package anatomy guide covers the Studio’s campaign ZIP, a different package; the methodology states this engine’s rules beside the rest.

Questions

Do I need to rename anything before copying the files?

No. The ZIP's name is the site name passed through the slug rule, but every file inside keeps the fixed name the snippet and the manifest expect. Copy them as they are to the public root of the site.

Which files does the snippet declare, and which does the manifest?

The snippet declares favicon.ico, the two smallest PNG favicons, the Apple touch icon, the manifest itself and the theme colour. The manifest declares the two Android icons and their two maskable twins. The two remaining PNG favicons are in the ZIP but are declared by neither the snippet nor the manifest; the browser reaches them only through the ICO.

How much larger than its four PNGs is favicon.ico?

Exactly 70 bytes: a 6-byte header plus four 16-byte directory records, measured from the engine's ICO builder at build time. The PNG bytes inside are the four small renders copied unchanged.

Where are the exact pixel sizes written down?

In README.txt under Included, which lists every size, and in the file names of the favicon, Android and maskable PNGs; the Apple touch icon's size appears in the snippet's link instead. The sizes live only inside the engine's render function, so this guide names them in words and does not say which platform uses which.

My logo has a transparent background. Do the maskable files keep it?

No. A maskable render fills the whole square with the background colour and ignores the transparent switch, so the mark sits on solid colour with padding raised to a floor of a fifth of the side when the slider asks for less. Only the standard files can carry the transparency, along with the chosen shape and the slider's own padding.

Where does the theme colour in the snippet come from?

From the design's background colour, written as picked. The same value fills the manifest's theme_color and background_color; the engine offers no separate theme-colour field, so changing the background changes all three.