Generate a Favicon Set for a Small Website

A favicon set gives browsers and devices small versions of your site's identity for tabs, bookmarks, and supported app experiences. Generating several files is only part of the job: the source must remain recognizable when reduced, the HTML must point to the files you actually deploy, and any web app manifest needs your site's real name and colors. This guide walks through the whole setup.

Start with a source that survives reduction

Choose a simple mark with strong contrast and a clear silhouette. A detailed wordmark, thin lettering, or several small shapes may look polished at full size and turn into an unreadable blur at 16 pixels. If the full logo cannot be simplified enough, use a distinctive symbol or monogram for small icons and reserve the complete wordmark for larger contexts.

Prepare the source as a square composition, with the mark centered and enough padding that its edges are not clipped. Check whether the icon will have a transparent background or a solid one. Transparent regions can show the browser's tab background, but a transparent mark with thin light shapes may disappear in a dark theme. A solid background can improve contrast if it matches your brand and the platform requirements.

Use a high-resolution source so downscaling has enough detail to work with. If your starting image is a small raster, enlarging it does not restore missing edges. A vector source such as SVG can scale cleanly, but confirm how your export workflow handles it. If you use a raster source, inspect the reduced previews at actual size rather than judging only the large original.

Choose the icon files your site needs

A favicon can be supplied in different formats and sizes. The right set depends on the browsers and device experiences you support. A typical small-site set may include PNG icons for browser tabs and a larger touch icon, plus a web manifest for installable app experiences if the site supports them.

The Toolsnix Favicon Generator creates PNG files at 16, 32, 48, 180, 192, and 512 pixels square, along with a site.webmanifest, an HTML snippet, and a README in a ZIP download. These sizes are fixed in its current implementation. The generator also scales the source directly into a square canvas, so prepare a square image first to avoid stretching a non-square logo. Its manifest currently contains placeholder name, short name, theme color, and background color values; customize those for your project before deployment.

Do not include every possible icon format without a reason. Keep the files you reference in your markup or manifest, and remove stale references that point to assets you no longer deploy. If an organization has an existing favicon or brand system, follow that before creating a separate icon style.

Add the HTML references

Place the generated files at the paths used by your HTML links. The <link> elements belong in the document head. A typical setup might look like:

<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/site.webmanifest">

These are example paths; use the names and public paths that exist in your project. If your site uses a framework or a static-site generator, add the links through its metadata or document-head mechanism rather than copying the snippet into a component that renders in the wrong place. Avoid duplicate conflicting icon declarations in multiple layouts.

Paths also depend on where the site is hosted. A root-relative path such as /favicon-32x32.png points from the domain root; it may be wrong when an app is deployed under a project subpath. A relative path such as favicon-32x32.png resolves from the current document location, which can also behave differently across routes. Use the asset path strategy already established by your framework and verify the icon URL from both the homepage and a nested page.

The browser may cache icons aggressively. After deployment, request the actual file URLs directly and inspect the page source or rendered head to confirm that each link resolves. A working development path does not guarantee the deployed path is correct, particularly if the app uses a subdirectory, CDN, or custom asset prefix.

Customize the web app manifest

A web app manifest is a JSON file that describes an installable web application in supporting browsers. It may include the app's name, short name, icon references, display preferences, and theme colors. The manifest does not replace the site's page title or the favicon links.

Review each generated field before using the file:

• Set name to the product or site name users recognize.
• Set short_name to a concise label appropriate for constrained displays.
• Confirm each icon src, sizes, and type matches the deployed file.
• Choose theme_color and background_color that match your actual experience.
• Keep only the display behavior the app is designed to support.

A manifest with placeholder branding can make an app install prompt look unfinished or misleading. Validate the JSON syntax and test the manifest URL after deployment. If your project is not intended to be installed as an app, a manifest may not be necessary just because an icon tool generated one.

Check the icon at real sizes

Inspect the 16- and 32-pixel previews first. Look for features that merge together, thin strokes that vanish, and negative space that closes up. If the icon is not recognizable, simplify the source rather than relying on a browser to interpolate it well.

Then check the larger touch and app icons. The mark should remain centered and have suitable padding within the square. Some device launchers may apply their own masks or presentation, so do not assume a square source will be displayed with sharp square corners everywhere. Follow current platform guidance for installable icons if you target a particular device ecosystem.

Test in the browsers and devices that matter to your audience. Different browsers may select different declared resources or cache previous icons. The tab icon, bookmark icon, home-screen icon, and installable app icon may not all use the same file.

Example: a wordmark and a simple mark

Suppose a small company has a horizontal logo that spells out its name beside a star symbol. At 16 pixels, the entire wordmark becomes too small to read. A better source for the favicon may be the star alone, centered in a square with enough padding. The larger touch icon can use the same symbol on the brand background, while the full wordmark remains in the page header.

If the company only has the horizontal file, do not force it into a square by stretching. Create a square composition with an appropriate background or ask for an icon version of the brand mark. After generation, compare all sizes and decide whether the 16-pixel icon needs a simpler shape than the larger icons.

Deploy and verify the set

Before release, compare the file list with the references in your head and manifest. Confirm that paths are case-correct, images return successfully, and the manifest parses as JSON. Open each image directly to make sure it is not corrupted or the wrong file.

If the browser continues to show an old icon, try a private window or clear the relevant cache to distinguish caching from a bad path. Avoid changing file names repeatedly without updating every reference. A versioned filename can help when an icon genuinely changes, but the HTML and manifest must point to the new one.

A useful verification checklist:

1. The source is square or has been composed into a square without distortion.
2. The small previews remain recognizable at 16 and 32 pixels.
3. The larger touch/app icons use the right branding and background.
4. The HTML links point to files that are deployed at those paths.
5. The manifest has project-specific values and valid icon references.
6. The actual tab, bookmark, and target device experiences have been checked after deployment.

Favicons are not a substitute for a good page title, site name, or accessible brand presentation. They are a small interface cue that helps people identify a page among many tabs or saved links.

Common mistakes

• Using a detailed logo at 16 pixels: Reduce it to a distinctive mark or monogram.
• Stretching a horizontal source to a square: Compose into a square canvas or use a square mark.
• Ignoring transparency: Test the icon on light and dark browser surfaces.
• Leaving placeholder manifest fields: Replace sample name and colors with actual project values.
• Referencing files that are not deployed: Check every URL and path after the build.
• Expecting the browser to update immediately: Cached icons may require a refresh or cache check.
• Treating all icon contexts as identical: A tab favicon and a larger home-screen icon may use different files and presentation rules.

Frequently asked questions

What favicon sizes should I create?

The required set depends on the browsers and device experiences you support. Common workflows include small browser icons and larger touch or app icons, but check the current platform requirements and use only files your site references.

Can I use an SVG favicon?

Some browsers support SVG favicons, but support and behavior can differ by browser and workflow. If you use SVG, test it in your target browsers and provide fallback resources where needed.

Why does my favicon look blurry?

The source may be too detailed or low-resolution, the browser may be using a small raster file, or the icon may have been stretched. Simplify the mark, use a suitable source, and inspect the exported 16- and 32-pixel versions.

Why does the browser still show my old favicon?

Favicons are often cached. First confirm that the current page references the new deployed file and that the path returns the expected image. Then test in a private window or clear the cache if necessary.

Do I need a web manifest for a favicon?

No. A manifest is useful for supported web app installation experiences, but a site can reference favicons without having an installable app. Use the manifest only when it serves your project and customize its values.

Next step

Prepare a simple square source, generate the icon files, replace any placeholder manifest values, and add references that match the deployed paths. Check the smallest preview and test the icon in the browsers and devices your site supports before calling the setup complete.

Sources

• MDN: The HTML <link> element
• MDN: Web app manifests

Keep the source artwork available

A favicon is a small derivative, not the best place to store the only copy of a mark. Keep the original logo or vector artwork in the project’s design source, then document how the simplified icon was created. If the brand changes, this makes it possible to regenerate the set instead of editing a tiny, already-rasterized image and losing clarity. Review the icon on both light and dark browser surfaces; a transparent mark can nearly disappear when its contrast depends on a particular background.