favicon.im 實測：一條網址抓任何網站圖示，抓不到有三條退路

Facebook Line Messenger Telegram

想在網頁或 App 裡顯示其他網站的圖示，你手上其實早就有一條免費路：Google 有個貼上網域就回圖的端點，DuckDuckGo 也有同性質的服務，都不用註冊、不用金鑰。所以 favicon.im 這個站值不值得用，第一個要問的就是它比那些內建選項多給了什麼。實測之後我的答案是：它把「圖示抓不到怎麼辦」做成三選一，其中服務端轉址那條是內建端點沒有的；但它的「即時」其實是快取、「大圖」其實因站而異，而且嚴格說起來，你並沒有真的繞過 Google。

先講這個需求本身。書籤管理器、連結卡片、後台的客戶列表、搜尋結果頁，任何「一口氣秀出一排網站」的介面都需要圖示，而每個網站把圖示放哪裡、用什麼格式都不一樣：有的老老實實放在根目錄的 favicon.ico，有的藏在 HTML 的 link 標籤、web manifest 或 Apple touch icon 裡。自己寫抓取程式不難，難的是長期維護：網站改版換路徑、有的站根目錄根本沒有 ico 檔、有的只提供 SVG，這些分支處理加起來就是一段永遠在修修補補的程式碼。交給一條現成網址處理，通常划算。

一條網址直接用：實測回傳長什麼樣

用法就是把網域接在後面：https://a.favicon.im/github.com。實測 github.com 回傳 SVG 原檔（959 bytes），zeabur.com 回傳 192×192 的 PNG，google.com 回傳 32×32 的 PNG。格式由服務決定，回傳目標站現有的最佳版本；文件上寫明回傳「可取得的最佳格式」，參數也只有尺寸和備援相關的三個，沒有指定輸出格式的選項。速度方面，第一次抓冷門網域大約 1.1 秒，第二次命中快取約 0.2 秒，日常掛在頁面裡的體感就是快。

不用申請帳號、不用 API 金鑰，站方還明講歡迎直接連它的網址，不想自己管圖片儲存的人可以省一套快取邏輯。介面提供 18 種語言翻譯，繁體中文在列，輸入框、參數說明都中文化了。有個小地方要注意：google.com 那張 32×32 的 PNG，回應標頭的 Content-Type 標的是 image/x-icon，內容其實是 PNG。用 <img> 顯示完全沒差，但若有程式嚴格按 Content-Type 判斷檔案類型，就會判錯。

favicon.im 的繁體中文首頁，輸入網域就能即時預覽圖示（來源：favicon.im 官網截圖）

失敗處理做成三選一，是它跟內建端點的主要差別

先說一個會顛覆直覺的實測結果：Google 端點對抓不到圖的網域，跟完轉址之後其實是回 HTTP 404（夾帶一張 Google 預設圖），掛在 <img> 上會觸發 onerror 事件。也就是說，最常見的「用 onerror 換自己的備援圖」這招，Google 端點本來就吃。favicon.im 做的差異化在於把失敗處理明確列成參數，三種模式我都用不存在的網域逐一驗過：什麼都不加，回一張 257 bytes 的 SVG 佔位圖，狀態碼 200，畫面不會破圖；加上 throw-error-on-404=true，改回 HTTP 404，讓 onerror 接手；加上 default-avatar= 接你自己編碼過的圖片網址，回 302 直接轉址過去，備援圖交給服務端處理，前端一行程式都不用改。

官方 API 文件頁：參數只有 larger、default-avatar、throw-error-on-404 三個，全部圍繞失敗處理（來源：favicon.im 官網截圖）

三種行為都跟文件一致，其中 404 模式的用法如下：

<img src="https://a.favicon.im/example.com"
     onerror="this.src='/fallback-icon.png'"
     loading="lazy"
     alt="example.com 的網站圖示" />

三種模式怎麼挑，看你的前端能改多少。畫面能用一張中性圖帶過就好的，預設模式最省事，什麼都不設也不會破圖；前端本來就有元件可以掛 onerror 的，用 404 模式把控制權拿回來，備援邏輯留在自己程式裡比較好維護；至於 default-avatar 轉址，適合不方便改前端程式的場合，例如版型寫死、或圖片網址由後端統一組給出的系統，把備援圖顧在服務端一勞永逸。

站方給的建議也算實在：圖多的頁面加上 loading=”lazy” 避免一次載入幾十張圖；用 Next.js 的人要把 a.favicon.im 加進信任的圖片網域清單。這兩個備援參數是 2026 年 1 月才加進來的，變更日誌上就這麼一筆，站的更新幅度不算大，但至少還在動。用量邊界方面，官方只說「合理使用範圍內完全免費」，沒有公布任何速率或流量數字，超大量請求要另外聯絡；沒有白紙黑字的額度，對要衝流量的專案來說是個模糊地帶。

「即時」的真相：兩層快取，末端還是 Google

首頁標題寫「即時網站圖示獲取器」，不過打開回應標頭看，實際行為是快取優先。站方文件說來源端的圖示快取 24 小時；回應標頭給的 cache-control 是 max-age 約 710,000 秒，8 天上下，那是 Cloudflare 邊緣節點那一層。它還會回一個自訂標頭 x-favicon-source，實測出現過 cache-fresh（快取有圖）、origin（回源去抓）、default（佔位圖）等值，等於把這次請求用了哪層快取攤給你看，要 debug 圖示為什麼沒更新時，看這個標頭比瞎猜快。

快取優先對使用者的實際意義：目標網站換了圖示，你這邊最慢可能要等快取走完一輪才看得到新的。做連結列表、書籤牆這類應用無所謂，反正讀者要的是「認得出這是哪個網站」，圖示晚幾天跟上完全無感；但如果你想拿它來驗證「某網站此刻的圖示長什麼樣」，例如品牌監控、設計取材，這個工具的答案最多是新到上一輪快取，快取還沒到期時，你看到的永遠是上個版本的圖，有時效性的專案要心裡有數。

還有一個多數人不會注意到的結構：這個服務自己的抓取來源鏈，最後一關是 Google 的 favicon 服務。站方 FAQ 寫得很直白，搜尋順序是 HTML link 標籤、web manifest、Apple touch icon、根目錄 favicon.ico，都沒有就交給 Google 收尾。所以用 favicon.im，某種程度上是在用一層「幫你快取、幫你處理失敗」的包裝，底層偶爾還是 Google 在供圖。認清這點不影響使用，但會影響你對「切換到它能降低對 Google 的依賴」這類念頭的期待。後端看起來跑在 Zeabur 這個託管平台上，前面掛 Cloudflare 當 CDN，官網說的「Cloudflare 全球邊緣網路」指的是 CDN 那層。

四個端點放在一起看

同一天用同一批網域實測四個選項，行為差異比宣傳頁面講得清楚：

	favicon.im	Google s2/favicons	DuckDuckGo icons	unavatar
免金鑰直接用	是	是	是	是
抓不到圖時	三選一：佔位圖／404／服務端轉址	回 404（onerror 可接手）	回 404	回 200 佔位圖
實測回傳（github.com）	SVG 原檔 959 bytes	PNG 32×32	ICO（16 與 32 兩種尺寸）	PNG 32×32
可自架	否，站方明說只有託管版	否	否	可以，MIT 開源

四個 favicon 端點對照，截至 2026 年 9 月以實測與官方文件整理。

表裡有個耐人尋味的細節：unavatar 抓 github.com 回的檔案，在其中一次實測裡跟 Google 端點連位元組都相同（另一次 Google 端自己換了版本，兩邊才岔開），推測不少同類服務底層共用同一批來源。算不上缺點，但可以修正你的期待：這一類工具比的是快取層和失敗處理，比的不是誰的圖比較漂亮。

換成情境來選會更具體。側欄連結列表、個人部落格的友好站連結，Google 或 DuckDuckGo 端點加一行 onerror 就夠，不用多一個依賴；大量網域、想要「沒圖就顯示中性佔位圖」的後台介面，favicon.im 的預設模式省事，default-avatar 轉址還能讓備援圖統一由你自己的 CDN 出；客戶對外看得到的產品畫面、或有合規與供應商審核要過的場景，自己架一套 unavatar 或自己寫，把這條依賴收進自己的控制範圍。

官網標示和實測對不上的地方

尺寸是最明顯的一個。google.com 的下載頁把 larger=true 那個選項標成 128×128，實際拿回來是 32×32 的 PNG，跟沒加參數一模一樣，連檔案大小都同樣是 1,322 bytes。文件用的字眼其實是「最大 256px，視來源而定」，zeabur.com 就真的拿到 192×192，但下載頁直接標了一個固定尺寸，容易讓人以為有保證。要大圖的專案，上線前請針對自己會用到的網域先驗一輪。

google.com 的專屬下載頁，標示 128×128 的選項實際回傳 32×32（來源：favicon.im 官網截圖）

CORS 的宣稱也對不上。API 頁的功能列表寫「CORS 已啟用」，實測帶 Origin 的請求、連 OPTIONS 預檢在內，回應裡都沒有 Access-Control-Allow-Origin 標頭。用 <img> 引用不受影響，因為本來就不需要 CORS；但如果你要把抓來的圖丟進 canvas 讀取像素，會被瀏覽器的同源政策擋下來，這種進階用法目前行不通。

至於網路上流傳的舊用法，網址寫 favicon.im/zh/網域?size=32 那種，現在還能動，但 size 參數加了跟沒加一樣，實測回同一個檔案。還有個更隱蔽的差異：同一個 google.com，走 a.favicon.im 拿到的是 1,322 bytes 的 PNG，走 /zh/ 舊路徑拿到的卻是 5,430 bytes、包了 16 與 32 兩種尺寸的 ICO。舊路徑沒有文件背書，行為也不保證，新專案照現行文件寫就好。

下載頁與熱門排行：這個站把自己做成了圖示目錄

favicon.im 不只是一個端點，站方圍著這個需求蓋了一整個內容生態。每個網域都有專屬下載頁，標好尺寸選項，抓得到大圖時會順帶提取品牌色票（抓不到就顯示暫無配色）、附一段自動生成的圖示描述，例如 google.com 的英文版頁面上寫的是「一個模糊的多彩小寫 g」，描述由機器生成，偶爾會冒出「模糊」這種怪修飾；繁中版頁面則是另一份中文描述，參考就好。另外有以請求熱度排序的網域排行頁，對「想找常見網站圖示」的人是現成入口，不過站方自己也標明排行數字是估計值。

內容端更完整：從 WordPress、Shopify 到 Next.js、Nuxt 的 favicon 設定教學一系列十幾篇，加上圖片轉 favicon 的八種格式轉換器、emoji 圖示產生器。看得出這是個以搜尋流量為主的內容生意，廣告就掛在這些頁面上。對讀者的意義有兩面：內容和工具確實好用，順路查資料很方便；但整站看不到公司名稱，對外聯絡管道是一個 X 帳號，頁尾外連 20 多個同風格的工具站，從 logo 產生器到網域查詢都有，看起來是單人或少數人經營的系列網站。

嵌進正式專案前，先看清條款與自架限制

官網沒有服務條款、沒有隱私政策，連 about 頁都沒有，這幾個網址全部是 404。免費服務加上零條款，代表服務水準、資料處理方式、停機責任都沒有白紙黑字，連「合理使用」的邊界都由站方單方面認定。看得到的商業模式是廣告（首頁和介面頁掛 Google AdSense，API 文件頁反而乾淨）加上一個請喝咖啡的贊助連結。這不代表服務不能信，30M+ 的每月請求量、99.9% 的上線率、100ms 以下的平均回應，這些數字官網都寫得很大器，但都是站方自稱，站外找不到能對上的獨立資料。

對有治理要求的團隊，關鍵限制在於它不能自架。FAQ 對「能不能自己架一套」的答案是不能，自架需求請找 GitHub 上的開源替代品；後端跑在哪個託管平台，使用者也只能從回應標頭反推。定位因此很清楚：方便的預設選項，而非唯一的依賴。繁中介面大致翻得完整，輸入框、參數說明、常見問答都是中文，但角落沒做完：首頁那顆把圖片轉成 favicon 的按鈕在繁中版仍是英文，下載頁由機器生成的圖示描述，繁中版甚至整句直接用簡體字。功能不受影響，就是那種會讓人覺得差一步的細節。

內部工具直接嵌，關鍵路徑自己來

個人專案、內部工具、想最快上線的連結列表，直接嵌，記得用 onerror 綁自己的備援圖；這一步做了，前面講的風險就抵銷掉大半。產品關鍵路徑、或對第三方依賴有合規要求的場景，可以考慮自己架一套 unavatar，或乾脆寫支小服務自己抓，來源鏈就那幾步，官方文件都攤開了。最後那個問題也一樣：如果你是為了「拿大圖」才考慮它，先別假設，針對你的目標網域實測一輪再說。

順路的延伸：抓下來的圖示若是 SVG 想壓小，可以看SVG Optimizer 的實測；要替自己的網站做一枚 favicon，線上 SVG Favicon Maker 是現成產生器；需要大量圖示素材並搞懂商用授權，Flaticon 的授權解析整理過一輪。