Favicon 格式解析：ICO、PNG、SVG 與瀏覽器需求

為什麼 favicon 仍然出奇地複雜

favicon 看起來只是一張小圖片，但它位在瀏覽器介面、書籤、分頁、釘選捷徑、搜尋結果、行動裝置主畫面，以及 progressive web app 安裝之間。每個情境都有些微不同的期待。

這就是為什麼 favicon 的建議經常顯得混亂。有些團隊只提供單一 favicon.ico，因為過去這樣就夠了。另一些團隊則產生十幾個檔案，卻不知道哪些實際上會被使用。合理的中間路線更小：理解 ICO、PNG 和 SVG 各自擅長的事，然後提供一組精簡檔案，涵蓋目前的瀏覽器與常見裝置情境。

favicon 不是用來展示圖片處理流程的地方。它應該無聊、明確，而且相容。

ICO：拒絕消失的老格式

ICO 是經典的 Windows 圖示容器。它可以容納多個不同尺寸的點陣圖，常見如 16×16、32×32 和 48×48 像素。這很重要，因為 favicon 可能在瀏覽器分頁中以很小的尺寸顯示，在書籤清單中較大，在 Windows 捷徑上又以不同方式呈現。

重要的是，ICO 是容器，不只是單張圖片。好的 favicon.ico 通常包含多個點陣尺寸，讓瀏覽器或作業系統可以選擇最接近的版本，而不是縮放單一的小點陣圖。

ICO 仍然有用，原因有三個：

• 瀏覽器可能會自動請求 /favicon.ico，即使你沒有在 HTML 中連結它。
• 有些較舊的瀏覽器與整合環境仍然期待它。
• 當較新的圖示宣告被忽略時，它是安全的備援。

這不代表 ICO 應該是你唯一的圖示。它不易編輯，對現代工作流程也不特別友善，更不適合作為品牌標誌的唯一真相來源。把它視為相容性備援即可。

實務上，請在網站根目錄放置真正的 /favicon.ico。除非你喜歡吵雜的記錄檔和不必要的瀏覽器重試，否則不要讓那裡回傳 404。

PNG：可靠的主力格式

PNG 仍然是 favicon 與觸控圖示最可預期的點陣格式。它支援透明度、支援範圍廣，並且在各種瀏覽器與平台上的行為一致。

對 favicon 來說，當你想要明確像素尺寸的圖示，例如 32×32 或 48×48，PNG 很有用。對行動裝置主畫面圖示來說，在某些環境中 PNG 幾乎是必要的。例如 Apple touch icon 在一般正式使用中就是以 PNG 為基礎。

幾個實用規則會有幫助：

• 從向量來源匯出，而不是從已經很小的點陣圖匯出。
• 先讓圖示在 16×16 時清晰可辨，再關心更大的尺寸。
• 加入足夠留白，避免標誌在圓角或遮罩情境中顯得被裁切。
• 避免細小文字、細線與複雜插圖。

對 favicon 來說，PNG 壓縮通常不值得過度執著，因為檔案很小。不過，也不要因為它直接來自設計匯出，就放上一個 500 KB 的 touch icon。如果你已經在檢視更廣泛的圖片選擇，那麼現代 Web 上的圖片格式決策中同樣有紀律的思考也適用於此：為任務選擇格式，而不是因為它很流行。

SVG：現代且彈性的選項

SVG favicon 很有吸引力，因為它與解析度無關。單一小檔案可以在多種尺寸下清楚呈現，也可以直接在程式碼中編輯，或從設計軟體匯出。

現代 Chromium、Firefox 和 Safari 版本都支援 SVG favicon。這讓 SVG 成為許多網站很好的主要 favicon 格式，尤其當圖示是簡單的 logo、字形或幾何標誌時。

但 SVG favicon 也有注意事項。

首先，SVG 應該是自包含的。不要依賴外部字型、遠端圖片或 script。瀏覽器會對作為圖片使用的 SVG 套用限制，而且即使某些東西在一個瀏覽器中可行，也可能在另一個瀏覽器中失敗。

第二，保持視覺簡單。SVG 不會神奇地解決 16 像素問題。複雜的向量插圖在被壓進分頁時仍然會變成一團模糊。

第三，小心動態樣式。有些團隊會在 SVG favicon 裡使用 prefers-color-scheme，讓圖示適應深色與淺色瀏覽器主題。這可以運作，但瀏覽器行為與快取可能不一致。如果品牌辨識很重要，單一穩健的圖示通常勝過聰明的自適應圖示。

SVG 是好的來源格式，也是好的現代交付格式。但它不是跳過備援檔案的理由。

瀏覽器實際上會尋找什麼

瀏覽器主要透過兩種方式發現 favicon：明確的 HTML 連結，以及隱含的根目錄請求。

隱含行為是舊做法：如果瀏覽器想要圖示但尚未找到，它可能會請求 /favicon.ico。這就是為什麼即使在現代網站上，根目錄 ICO 檔案仍然有用。

明確行為則使用文件 head 中的 <link> 元素。一個精簡的現代設定看起來像這樣：

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

manifest 接著可以指向用於可安裝 Web App 的較大 PNG 圖示：

{
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

這不是唯一有效的設定，但它是很好的基準。它提供現代瀏覽器 SVG，提供傳統 ICO 備援，涵蓋 iOS 主畫面儲存，並支援 App 安裝情境。

多數網站應該提供的 favicon 組合

對一般行銷網站、文件網站、SaaS App 或出版網站而言，這組就足夠：

• /favicon.ico 包含 16×16 和 32×32，可選擇加入 48×48。
• /icon.svg 作為現代可縮放 favicon。
• /apple-touch-icon.png，尺寸為 180×180。
• 如果你有 web app manifest，則提供 /icon-192.png 和 /icon-512.png。

如果某個平台有特定需求，你可以加入更多尺寸，但不要因為習慣就產生十個檔案。每多一個檔案，就是另一個需要快取、可能被忘記、命名錯誤，或在品牌重塑後留下過時版本的東西。

如果你的網站不可安裝且沒有 manifest，你可能不需要 192 與 512 像素圖示。如果你的網站行為像 App，你可能就需要。

常見失敗模式

最常見的 favicon 錯誤不是美術問題，而是交付問題。

其中一個是過於積極的快取。瀏覽器會頑固地保留 favicon。測試期間，變更後的圖示可能要等到你強制重新整理、清除網站資料、使用新檔名，或在全新設定檔中測試才會出現。對正式環境的品牌重塑而言，在 HTML 中改成 /icon.svg?v=2 可能有幫助，但根目錄的 /favicon.ico 比較麻煩，因為瀏覽器會直接請求它。替換檔案並等待快取過期，往往是工作的一部分。

另一個常見問題是錯誤的 MIME 類型。SVG 應以 image/svg+xml 提供，PNG 以 image/png 提供，ICO 通常以 image/x-icon 或 image/vnd.microsoft.icon 提供。許多瀏覽器很寬容，但不是所有情境都如此。如果某件事只在某個瀏覽器失敗，先檢查網路回應，再重畫圖示。這裡也適用在正式環境除錯重新導向與 HTTP headers時的相同習慣：查看實際回應，而不是 CMS 聲稱它正在提供什麼。

第三個問題是設計密度。在網站頁首中非常漂亮的 logo，常常作為 favicon 時失敗。分頁圖示是嚴苛的測試。移除文字、簡化形狀、提高對比，並以實際尺寸測試。如果圖示是頁面內有意義的內容，那麼像 alt 文字這類可及性考量就很重要；但 favicon 本身是瀏覽器介面的裝飾，不是頁面內容。關於這個區別，請參考我們的圖片 alt 文字實務指南。

<!-- tool-cta:start -->

💡 試試這個: 使用 Ultimate Favicon Generator 一次產生現代瀏覽器所期望的 ICO、PNG 和 SVG 變體。

<!-- tool-cta:end -->

簡單的實作檢查清單

發布前請使用這份檢查清單：

1. 從乾淨的向量主檔開始。
2. 在 16×16 和 32×32 測試標誌。
3. 匯出自包含的 SVG favicon。
4. 產生多尺寸 ICO 備援。
5. 匯出 180×180 Apple touch icon。
6. 如果使用 manifest，加入 192×192 和 512×512 PNG。
7. 將 /favicon.ico 放在網站根目錄。
8. 驗證狀態碼、MIME 類型與快取 headers。
9. 如果你的受眾包含 Apple 裝置，至少在一個 Chromium 瀏覽器、Firefox 和 Safari 中測試。

favicon 很小，但也非常顯眼。壞掉的 favicon 會讓網站感覺尚未完成。做得好的 favicon 會消失在介面中，而這正是重點。