Favicon Sizes and Formats: A Practical Guide

A favicon is often the smallest version of a product symbol that users encounter. Browser tabs, bookmarks, and saved shortcuts do not all present artwork in the same way. A dependable favicon set starts with a readable drawing and then supplies appropriate files and declarations for the contexts you support.

Design the smallest symbol before exporting files

Start at 16 pixels, where elaborate detail usually collapses. Use a simplified mark with a strong silhouette, generous internal gaps, and no dependence on fine text. The favicon generator helps prepare favicon declarations; review the resulting file references against the assets you actually create and deploy.

Do not assume the tool replaces drawing review or creates every platform asset your application might need. Keep a checklist of required outputs, then verify each one independently. A valid link tag pointing to an absent file is still a broken favicon setup.

Make a proof sheet at 16, 32, and 48 pixels. These are useful inspection sizes rather than an exhaustive platform specification. Compare the symbol on light and dark browser-like surfaces. If it only works when enlarged, simplify the drawing before spending time on packaging.

Distinguish SVG, ICO, and PNG roles

An SVG favicon can remain sharp across sizes and can include media-query styling where supported. It is useful for modern browsers, but support and selection behavior should be tested against the environments that matter to your product.

An ICO file can contain multiple raster sizes and remains a practical compatibility asset. Make sure the file is a real ICO container, not a PNG renamed with an ico extension. The individual raster images should be reviewed at their native dimensions.

PNG files are useful for contexts that expect raster artwork, including certain saved-home-screen behaviors. Do not treat a browser-tab icon and a home-screen icon as interchangeable merely because both use the same underlying symbol.

The MDN icon link documentation explains rel="icon". The MDN image type guide provides format context. Use these sources to verify declarations rather than copying an oversized historical favicon bundle without understanding its files.

Declare a small, understandable set

A basic set can include an SVG icon, an ICO fallback, and a separate touch icon when that context is supported. Keep the declarations explicit and confirm that every path resolves from the deployed site root.

<link rel="icon" href="/favicon.ico" sizes="16x16 32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml" sizes="any">
<link rel="apple-touch-icon" href="/apple-touch-icon.png"
    sizes="180x180">

The ICO sizes in this example must describe images actually present in the file. The touch-icon dimensions must match the exported PNG. Do not preserve sample declarations whose assets you did not produce.

If the application has a web app manifest, treat its icons as another documented set of outputs, not as an automatic replacement for every link declaration. Check the MDN manifest icons reference for purpose and size fields.

A minimal asset set is easier to inspect and maintain than a directory of unexplained variants. Add an output because a supported context needs it, then document that context alongside the export.

Adapt the artwork for tiny raster sizes

A large symbol reduced automatically to 16 pixels can lose the gap that makes it recognizable. Create a small-size master if necessary. Widen a counter, remove a secondary line, or slightly thicken a fragile diagonal while preserving the symbol's identity.

Use the image resizer calculator to plan proportional exports. The calculator helps with dimensions; it cannot judge whether automatic resampling preserved the intended silhouette. Inspect the pixels after export.

Avoid placing a full wordmark inside the favicon canvas. Even short names often become texture at tab scale. A single letter can work, but only if its distinctive structure survives the smallest rendering and does not require unusually delicate spacing.

If the artwork has a transparent background, test its edges against both light and dark surfaces. Pale details may disappear on one, while dark outlines may disappear on the other. A compact contained shape can provide consistency, but it also consumes precious interior space, so compare both approaches at actual size before deciding.

Verify selection, delivery, and updates

Browsers can cache favicons aggressively, making update testing less obvious than changing an ordinary page image. Use a clean browser profile or another controlled cache state when checking a new set. Confirm the network response before assuming the browser ignored the declaration.

Check the following:

1. Each declared file returns the expected image rather than an HTML fallback.
2. Raster files contain the advertised dimensions.
3. The symbol remains identifiable in a crowded tab strip.
4. Light and dark browser surfaces both preserve the silhouette.
5. Saved shortcuts use the intended asset in supported environments.

Keep the favicon source and export recipe with your other icon assets. A future symbol change should not require reverse-engineering a collection of unrelated PNGs. The icons and illustration guides are a useful reference for maintaining that small-size drawing discipline.

Do not promise identical selection behavior across every browser and operating system. Instead, define the contexts you support and keep a verification matrix with a few representative devices. A tested, modest set is more dependable than an enormous collection of declarations that nobody has checked since they were copied.

Make a small-size optical correction

Consider a circular mark with a narrow central cutout. A mathematically proportional 16-pixel export may close that cutout visually, especially against a dark tab surface. Prepare a small-size master with a wider opening and slightly less interior detail, then compare it with the original at actual size. The goal is recognizable identity, not identical coordinates at every resolution.

Review transparency as part of this proof. Pale artwork on a transparent canvas can disappear on a light browser surface; adding an intentional containing shape may be more reliable than assuming the browser will supply contrast. Conversely, a solid rectangular background can look accidental when the rest of the identity expects a freestanding symbol.

Keep the corrected master separate from generated files, and document which raster sizes use it. When replacing an existing favicon, capture the old and new versions at the same display size so reviewers can judge recognition rather than export quality alone. Ask someone unfamiliar with the change to locate the product among several open tabs. If they hesitate because the silhouette changed too much, revise the correction before shipping the asset set.

Key takeaways

• Approve a readable small-size symbol before generating declarations.
• Use SVG, ICO, and PNG for documented supported contexts.
• Make declared dimensions match the delivered files.
• Inspect raster exports rather than trusting automatic downscaling.
• Test cache state, dark surfaces, and saved shortcuts separately.