把圖片「編進」HTML / CSS / JSON 內聯傳輸 — Base64 是過去 15 年前端工程師最常用的圖片打包方式。但什麼時候該 inline、什麼時候會反而拖累效能?Data URI 到底是什麼?Email 圖片為什麼一定要 inline?這篇用我們的 `image-base64` 工具當範例,釐清 Base64 的真實用途與避開三個典型誤用。
什麼是 Data URI?為什麼不直接用網址?
Data URI 是把檔案的內容 base64 編碼後直接寫進 URL,格式 data:image/png;base64,iVBORw0...。
好處是 0 個 HTTP request:瀏覽器不用再去拿一個 .png 檔。對小 icon、email signature、loading placeholder 特別好用。
壞處是 bundle 變大 ~33%(base64 編碼開銷)而且不能被 CDN cache(每個 HTML 文件都重新傳輸圖片)。所以 inline 只適合極小、不會重複的圖片。
什麼時候該 inline,什麼時候不該
該 inline:
- < 2 KB 的 icon / logo / placeholder
- Email 簽名檔(email client 多半擋外部圖片連結)
- 動態生成的 SVG / QR code(同一 session 用一次就丟)
- Critical CSS 內的背景紋路(避免阻塞 first paint)
不該 inline:
10 KB 的圖片 — 直接用 URL + HTTP cache 更快
- 會在多個頁面重複出現 — CDN cache 才能省 request
- 需要 lazy load 的圖 — Base64 寫在 HTML 內無法延遲載入
經驗法則:不確定就用 URL。Inline 是優化的最後一哩,不是第一步。
Data URI vs raw Base64 vs HTML img vs CSS background
同一張圖,輸出格式有四種常見用途:
- Data URI:
data:image/png;base64,xxx— 給<img src>或<a href>用 - raw Base64:
xxx(不含data:image/png;base64,前綴) — 給 backend API、JSON payload 用 - HTML img 標籤:
<img src="data:image/png;base64,xxx" alt="">— 直接貼進 HTML - CSS background:
background-image: url("data:image/png;base64,xxx");— 給 stylesheet 用
工具一次給你 4 種,複製哪一個看當下情境。最容易搞錯的是 raw vs Data URI,前者用在 JSON,後者用在瀏覽器渲染。
反向解析:貼 base64 → 預覽 + 下載
另一個常見需求是反向:Slack / GitHub Issue / API response 收到一坨 base64 字串,想知道是什麼圖。
手動方式:寫 <img src="data:image/png;base64,你的字串"> 然後 reload 瀏覽器 — 麻煩且容易搞錯前綴。
工具的反向模式:直接把字串貼進去,自動偵測格式(JPEG / PNG / GIF / WebP / SVG)、檢查是否有 data: 前綴、render 預覽、提供下載按鈕。debug API 或 webhook payload 時超實用。
為什麼 email 圖片一定要 inline?
Email client(Gmail / Outlook / Apple Mail)預設會擋外部圖片,因為點開圖片會把你的 IP / email 位置告訴寄件方,變成追蹤工具。
所以行銷信、活動邀請、簽名檔的圖必須 inline(Base64 嵌進 HTML email body),收件人才看得到。不過 inline 也有成本:email body 變大、被 spam filter 標記機率提高。
業界實務:logo / signature 用 base64 inline(< 5 KB),主視覺 hero image 用 CDN URL 但加 https:// 直連自家網域(不要用第三方圖床)。Gmail 至少這樣信任度高一點。
下次寫 email signature 或調 critical CSS,記得用 圖片轉 Base64 工具 一鍵產出 4 種輸出,圖片不會上傳到任何伺服器,本地 base64 編碼後直接複製走。