Favicon Size Guide: Every File, Dimension, and HTML Tag You Need
faviconsweb developmentwebsite assetsHTMLbrowser compatibility

Favicon Size Guide: Every File, Dimension, and HTML Tag You Need

FFavicon Live Editorial Team
2026-08-03
6 min read

A practical favicon size guide covering PNG, ICO, SVG, Apple touch icons, web app manifests, HTML tags, and testing.

A favicon is a small asset, but it appears in browser tabs, bookmarks, history, shortcuts, mobile home screens, and installed web apps. This practical favicon size guide explains which files to prepare, which dimensions matter, how PNG, ICO, and SVG differ, and how to connect everything with maintainable HTML and manifest code.

Overview

The right favicon setup depends on where your site or application will appear. A simple website may need only an SVG and a PNG fallback. A site that supports older browsers, desktop shortcuts, iPhone home-screen bookmarks, or a progressive web app should provide a broader asset set.

There is no single favicon size that works best for every context. Small interface placements benefit from a crisp 16 or 32 pixel image, while home-screen and app icons require larger source files that can be scaled down cleanly. Keep every icon square, use a simple silhouette or mark, and test it at the actual size users will see. Fine text and complex illustrations usually disappear when reduced.

A dependable baseline for a favicon for a website is:

  • favicon.svg: a scalable vector version for browsers that support SVG favicons.
  • favicon-32x32.png: a standard raster fallback for browser tabs and bookmarks.
  • favicon-16x16.png: an optional small raster version for contexts that request a compact icon.
  • favicon.ico: an ICO file containing 16x16, 32x32, and optionally 48x48 images when broad compatibility is useful.
  • apple-touch-icon.png: commonly prepared at 180x180 for iPhone and iPad home-screen bookmarks.
  • Manifest icons: commonly prepared at 192x192 and 512x512 for installable web app experiences, with a maskable variant when the design supports adaptive cropping.

These are practical production targets rather than a requirement to ship every file in every project. A favicon generator can help create consistent outputs, but inspect the generated files and test them in your deployment environment before publishing.

Checklist by scenario

For a basic website

  1. Create a square source artwork with enough padding to survive small displays.
  2. Export an SVG if the artwork is vector-based and a 32x32 PNG fallback.
  3. Place the files in a predictable public directory, commonly the site root or an assets folder.
  4. Add explicit link tags in the document head.
  5. Open a private browsing window or clear the relevant cache before judging the result.
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon-32x32.png" type="image/png" sizes="32x32">

For broader browser and shortcut coverage

Add an ICO file when your project needs a conventional fallback or supports environments that expect /favicon.ico. An ICO container can hold multiple bitmap dimensions, so it is more useful when it includes more than one size rather than simply renaming a PNG file.

<link rel="icon" href="/favicon.ico" sizes="any">

Do not treat PNG and ICO as interchangeable extensions. In a practical favicon PNG vs ICO comparison, PNG is straightforward, widely supported, and easy to inspect; ICO is a multi-image container that can package several small resolutions. Use the format that matches your compatibility requirements, and avoid adding duplicate tags without a reason.

For Apple home-screen bookmarks

Prepare a separate 180x180 PNG with a strong, centered mark. Home-screen icons are displayed differently from browser tab favicons, so the artwork may need more breathing room or a background treatment. Add the dedicated link tag:

<link rel="apple-touch-icon" href="/apple-touch-icon.png" sizes="180x180">

For a deeper review of filenames, dimensions, and markup, see the Apple Touch Icon Guide.

For a progressive web app

Create a web app manifest and reference it from the page. Include at least a regular icon set at useful sizes such as 192x192 and 512x512. If the icon may be placed inside a system-provided shape, create a separate maskable asset with generous safe-zone padding rather than assuming the regular icon will crop well.

<link rel="manifest" href="/manifest.webmanifest">
{
  "name": "Example App",
  "short_name": "Example",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512-maskable.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ]
}

Manifest requirements can vary with the browser, operating system, and application features you support. The PWA Icon Requirements Checklist and Maskable Icons Explained provide useful follow-up checks.

For React, Vite, Next.js, or GitHub Pages

The dimensions do not change because of the framework, but file placement and metadata conventions do. In React or Vite, confirm that public assets resolve from the site root. In Next.js, follow the App Router metadata and file-convention approach used by your project. On GitHub Pages, verify the deployed base path, custom domain behavior, and the final generated URLs rather than testing only the local development server. Use the relevant React and Vite Favicon Setup, Next.js Favicon Guide, or GitHub Pages Favicon Setup Guide when implementing those environments.

What to double-check

  • Dimensions: Confirm that the declared sizes value matches the actual pixel dimensions. Do not label a 512x512 file as 192x192.
  • Transparency: Check whether the mark remains visible on light and dark browser surfaces. A transparent icon may need a subtle shape or background.
  • Sharpness: Review PNG exports at 16x16, 32x32, and 180x180. A logo that looks excellent at large scale may need a simplified small-size variant.
  • Paths: Test every URL from the deployed domain. A leading slash, relative path, or framework base path can change where the browser looks.
  • Content types: Ensure the server sends an appropriate MIME type for SVG, PNG, ICO, and the manifest.
  • Manifest validity: Confirm that each icon is reachable, square, and represented correctly in the JSON.
  • Cache behavior: If an old icon persists after a redesign, inspect cache headers and consider a versioned filename such as favicon-v2.svg during the transition.
  • Brand consistency: Compare the favicon with your avatar, social profile image, and Open Graph image. These assets have different jobs, but a shared visual cue improves recognition. The guide to Open Graph Image vs Favicon vs Avatar explains the distinction.

Common mistakes

Using a large logo without simplifying it. Wordmarks, thin outlines, and detailed illustrations are difficult to read in a browser tab. Design a recognizable symbol first, then add detail only where the display size allows it.

Providing only one oversized PNG. Browsers can scale images, but a single file is not always the clearest or most compatible implementation. Supply an appropriate fallback and, where needed, separate home-screen and manifest assets.

Forgetting the HTML head. Uploading an image does not automatically connect it to every browsing context. Add the correct link tags and the manifest reference.

Testing only in development. A successful local preview does not prove that paths, MIME types, redirects, or cache rules work in production. Test the deployed URL and inspect requests in browser developer tools.

Assuming a maskable icon is just another large icon. Maskable artwork needs safe margins because the visible shape may be cropped. Keep important details away from the edges.

When to revisit

Revisit this favicon size guide whenever you redesign your brand, move hosting, change frameworks, add a PWA manifest, introduce a custom domain, or change deployment and cache rules. It is also worth checking before a seasonal planning cycle or a significant product release, especially if several teams publish assets independently.

Use this short maintenance routine:

  1. List every current icon file and its intended context.
  2. Open each asset at its target dimensions and remove detail that becomes unclear.
  3. Validate the HTML, manifest JSON, file paths, and response content types.
  4. Test browser tabs, bookmarks, mobile home-screen saving, and any installable app flow you support.
  5. Record the source artwork and export settings so the next update does not start from a compressed copy.

For a final implementation, keep the setup proportionate: a small site does not need an unnecessary collection of files, while a product with multiple platforms should document each asset deliberately. The best favicon system is the one that stays recognizable, loads from reliable paths, and can be updated without guesswork.

Related Topics

#favicons#web development#website assets#HTML#browser compatibility
F

Favicon Live Editorial Team

Technical SEO Editor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.