What the tool makes
The favicon generator takes one design — 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 renders a complete icon package from it on canvases in your browser. A chosen image is read by the browser’s own file reader and drawn locally; the tool’s notice line says so: loaded locally. Nothing was uploaded. The download is one ZIP of PNG icons, a multi-size favicon.ico, a web manifest, a head-markup snippet and a README.
The favicon packages guide takes those files one by one, with the ICO measured byte by byte and the manifest read field by field; the methodology states this engine’s rules beside every other tool’s. This page stays with the tool itself: what each control reaches, the order the render applies the controls in, why the preview and the download differ, how to read the notice line, and the two ways the package leaves the tab. The files get a paragraph each at the end, pointing at the guide.
The controls, and what each one reaches
The tool opens with a placeholder name, no image, the rounded shape, a solid background and the slider partway along its range, so the first preview is a monogram. Every control feeds the same design object, and every change to it re-renders the preview. The site or app namereaches four places in the download path: the label on the preview’s mock browser tab, the manifest’s name and short_name, the ZIP’s file name through the slug rule, and — only when there is no image — the monogram, which is the first character of the trimmed name, uppercased.
The logo or imagechooser accepts JPG, PNG, WebP and SVG, judged by the file’s declared type; anything else is refused with the notice Choose a JPG, PNG, WebP, or SVG image. and a file over a fixed size is refused with a notice naming the limit. An accepted file is read into a data URL and becomes the mark; a button under the chooser removes it and returns to the monogram. The background colour fills standard renders unless the transparent switch is on, fills every maskable render regardless, and is written into the manifest and the snippet as the theme colour. The monogram colour is used only when a letter is drawn; with an image it reaches no icon. The shape picks the clip for standard renders; the padding slider sets the margin on every edge; and the transparent switch applies to standard renders only.
The render: clip first, then the mark
Every icon in the package comes from one render function, called once per size and once more per maskable size. The order inside it matters. For a standard render the function creates a square canvas, clears it, builds the path of the chosen shape — a circle inscribed in the square, a plain square, or a rounded square whose corner radius is a fifth of the side — and clips the canvas to that path before anything is drawn. It then fills the background colour unless the transparent switch is on, and finally draws the mark. For a maskable render it skips the clip and fills the whole square with the background colour, whatever the shape and the switch say, then draws the mark.
The mark’s placement is a fit, not a crop: an image is scaled to fit the padded box on its longer side, keeping its proportions, and centred. But the fit happens inside a canvas that has already been clipped, so for a standard render the shape can still cut the mark. With the circle, any part of a square image that lies outside the inscribed circle is lost; with the rounded square, the corners are lost when the fitted image reaches into them. The lower the padding, the more of the image lies in those regions; at the slider’s lowest setting a square image fills the whole canvas and the circle removes its four corners entirely. Raising the padding pulls the fitted image inward until it sits inside the shape; that is the mechanism behind “leave breathing room”. The maskable renders are never clipped, so the same image is whole in those two files. Without an image, the monogram is drawn in a heavy weight of the Arial / sans-serif stack at a font size of 68% of the available box, centred with a slight downward offset; an empty name falls back to the letter P.
Padding: what the slider does to each file
The slider’s value is a percentage of the icon’s side. On every render the engine clamps it to its fixed range — never below zero, never above the engine’s own ceiling of 32%, which the slider’s top matches — and converts it to a fraction. For a maskable render the fraction is then raised to a floor of a fifthof the side when the request is lower; that floor is the one the engine applies to its maskable renders — the tool’s own “leave breathing room” rule — and the slider cannot lower it, with no figure here for what any platform masks. The pixel padding is the rounded product of the side and the fraction, and the box left for the mark is the side minus twice that, never less than one pixel.
Two consequences follow from that arithmetic and are worth seeing in the files rather than inferring from the label. First, one slider value can become a different whole-pixel margin at each size, and at the smallest sizes the rounding means neighbouring slider values can land on the same margin, so a one-step change may alter the large icons and leave the tab icon untouched. Second, above the floor every file in the package gets the same fraction; below it, the standard files keep the slider value while the two maskable files hold the floor, which is why those twocan look more padded than the rest at low settings and identical to the rest at high ones. The preview, rendered at one size only, shows one of those margins; the ZIP shows all of them.
Preview versus download
The preview is a single standard render of the design at one large size, made by the same function the package uses, then displayed three ways: as a small copy inside a mock browser tab beside the site name, as a large copy below it, and in a strip of fourframes labelled with pixel sizes. The strip is that one render scaled down by the browser, not the package’s files, and its largest frame is drawn smaller than its label says. Scaling a large render down is not the same as rendering small: the download draws each icon on its own canvas at its own size, so a tab icon in the ZIP is a fresh render on a sixteen-pixel grid, not a shrunken copy.
Two things the preview never shows. It is always a standard render, so the two maskable files — solid square, no clip, padding never below the floor — are never previewed; the ZIP is the only place to see them. And it is one shape at one size, so the per-size rounding of the padding described above is invisible in it. The preview also protects itself against stale work: each change starts a new render, and a render that finishes after a later one began is discarded rather than drawn, so the image on screen always matches the controls as they stand.
Reading the notice line
The notice line under the preview is the tool’s running account of what it did last, and it is announced to assistive technology as it changes. It opens by inviting an image or the first letter of the name. Choosing a file writes the file’s own name followed by loaded locally. Nothing was uploaded., a refusal names what was wrong with the file, and removing the image reports the return to the monogram. Pressing download replaces it with Rendering and packaging every favicon size... while the nine renders, the ICO and the ZIP are built, then with a line listing what the package holds once the browser has been handed the file. The second button writes its own line into the same place once its package is built.
Failures land in the same line. If the package cannot be built, the notice carries the engine’s own message — the render function’s when an image cannot be drawn or a canvas cannot be encoded, or the ICO builder’s — and the download does not start. If the preview itself cannot be rendered, the notice says so while the last good preview stays on screen. The line reports; it does not judge. Nothing in it comments on the design’s contrast, its legibility at the smallest size or its suitability as an icon, because this engine carries no such check.
The download and the save button
The ZIP is named from the site name through the site’s shared slug rule — lower-cased and trimmed, every run of anything outside a–z and 0–9 collapsed to one hyphen (an accented letter counts as outside), hyphens at either end removed — then -favicon-package.zip. Tracing one fictional name through everything the field reaches: the Grey Heron Press & Bindery is shown on the mock tab as typed, written into the manifest trimmed, gives the monogram an upper-case first letter even though it was typed lower-case, and downloads as the-grey-heron-press-bindery-favicon-package.zip, the run of spaces and the ampersand between the last two words collapsed together into a single hyphen. Leave the field empty and each destination falls back on its own: the tab reads Untitled website, the manifest’s name becomes Website, the monogram becomes the letter P, and the ZIP is promo-favicon-package.zip, from the slug rule’s own fallback promo.
Only the ZIP takes the slug. Inside it every file carries the fixed name the snippet and the manifest expect, so the package installs by copying, never by renaming. The second button calls the same package function again — the same files, built again rather than reused — and writes its own notice line; rather than handing the ZIP to the browser, it sends the built package — the rendered icons and the other files, never your source image — to the account’s saved-artifact library, which does leave your device, and it prompts you to sign in first. Neither button writes anything into your site; the README’s install steps remain yours to carry out.
The files, briefly
favicon.icois not a separate rendering: the engine’s ICO builder takes the four small browser renders as PNG entries and writes a 6-byte header and one 16-byte directory record per entry in front of their bytes, copied as they are, so the file is the four PNGs plus that directory. The builder accepts sizes from 1 to 256 and refuses an empty list with At least one PNG icon is required. and a bad entry with ICO entries require a size from 1 to 256 and PNG data.; the package never triggers either. The guide reads a fictional ICO back record by record.
site.webmanifest is JSON written from the design: the name and its short form, the two Android icons under purpose any and the two maskable icons under purpose maskable, the background colour as both theme and background colour, and a standalone display from the site root. The guide lists each field. favicon-snippet.html is six lines for the page head — the ICO, the two smallest PNGs, the Apple touch icon, the manifest and a theme-colour meta — and README.txt gives fourinstall steps and then lists what is included, with each icon’s size in pixels — the one file that lists every icon’s size in one place; the snippet’s PNG lines, the manifest and the PNG file names each carry the sizes of the files they point at. The guide takes both line by line.
Where it stops
The engine honours the colours you pick exactly and applies no contrast check: a pale monogram on a pale background renders as asked, with no advisory; the preview and the downloaded files are the test. It does not inspect the image for suitability, remove a background or trace an SVG into vectors: an SVG source is decoded by the browser as an image and drawn at each size like any other bitmap, and no SVG icon is shipped. It accepts a file by its declared type, not by reading its bytes, and refuses the rest with a notice.
No platform figure appears on this page: the site’s specs registry, which dates every platform figure the site carries, has no entry for icon sizes, manifests or home-screen behaviour, and this page is built to fail rather than invent one. Nothing here says which file a browser or platform will choose, or how it masks an icon; the engine reserves a margin for a mask and stops there. The sizes it renders live only inside its render function, so — as the methodology does — this page names them in words. Which file a given browser or platform picks, and at what size, is for that platform’s own documentation to say.
Common misreadings
- “The image is never cropped.” The fit crops nothing, but a standard render is clipped to the shape before the image is drawn. With the circle or the rounded square at low padding, the corners of a square image fall outside the clip. The maskable renders are not clipped.
- “The preview strip shows the actual files.”It is one large render scaled down by the browser, with its largest frame drawn smaller than its label; the package’s icons are each rendered at their own size on download. Open the ZIP to see them.
- “What I see is what every file gets.” The preview is a standard render at one size. The maskable files are never previewed, and the pixel padding differs from size to size.
- “Transparent means transparent everywhere.” The switch affects standard renders only; maskable renders always receive the solid background.
- “More padding wastes space.”Padding is the margin that keeps the mark inside the shape clip, and the engine raises it to a floor on the maskable icons — its own “leave breathing room” rule — with no figure here for what any platform masks.
- “Changing the name changes the icon.”Only without an image, when the first character is the mark. With an image, the name reaches the other three of its four download-path places — the manifest, the ZIP name and the preview’s tab label — not the icon.
Questions
- Does my logo leave my device?
- Your source file does not: it is read by the browser's file reader, drawn onto canvases in the tab and packaged into the ZIP there, and the notice line reports it as loaded locally. Generating and downloading the package uploads nothing — the download hands the ZIP only to the browser. Saving the package to the library is a separate, explicit action that sends the built package — the rendered icons, never your source file — off your device, and prompts you to sign in first.
- Why are the corners of my logo missing in the browser icons?
- Because a standard render is clipped to the chosen shape before the image is drawn. With the circle, anything outside the inscribed circle is lost; with the rounded square, the corners are lost when the fitted image reaches into them. Raise the padding until the fitted image sits inside the shape, or choose the plain square. The two maskable files are never clipped.
- Why are there both standard and maskable Android icons?
- A standard render is clipped to the chosen shape and honours the transparent switch; a maskable render is a full square on the solid background with padding raised to a floor of a fifth of the side — the floor the engine applies to its maskable renders, with no figure here for what any platform masks. The manifest lists each pair under its own purpose.
- Why can't I see the maskable icons in the preview?
- The preview is a single standard render at one size, so the maskable path — no clip, solid square, padding never below the floor — is never shown. The ZIP is the only place to see those two files.
- Why does the maskable icon look more padded than the others?
- Because the engine enforces a minimum padding of a fifth of the side on maskable renders. Below that floor the maskable files get the floor while the standard files keep the slider value; above it, every file gets the same padding.
- What happens if I leave the site name empty?
- The preview tab reads Untitled website, the manifest's name falls back to Website, the monogram falls back to the letter P when there is no image, and the ZIP is named promo-favicon-package.zip from the slug rule's fallback, promo.
- What is inside favicon.ico, and why is it larger than one PNG?
- It holds the four small PNG renders behind a 6-byte header and one 16-byte directory record per entry, so its size is the four PNGs plus that directory. The PNG bytes are stored as encoded; nothing is re-rendered. The guide measures a fictional ICO record by record.
- Can I use an SVG as the source?
- Yes. The tool accepts JPG, PNG, WebP and SVG by declared type. An SVG is decoded by the browser as an image and scaled to fit the padded box at each size like a bitmap; the engine does not read or edit its markup, and the package contains no SVG.
- Why does the tool not warn me about low contrast?
- This engine applies no contrast check: the background and monogram colours are used exactly as picked, and the preview and the downloaded files are where to judge the result. The methodology sets out which engines carry a contrast advisory; this one does not.
- Which size does each browser or platform need?
- This page does not say: it carries no platform figures, because the site's specs registry has no entry for icon sizes and the page is built to fail rather than state one without a source. The package contains every size the engine renders; verify against the platform's own documentation.
Everything here runs in your browser: the tools compute on your device and the Studio’s package is assembled on the device. The methodology documents every rule the tools apply.