Base64 是一種二進位到文字的編碼方式，可以將任何檔案表示為一串可列印的 ASCII 字元。將圖片轉換成 Base64 意味著讀取 PNG、JPEG、GIF 或 WebP 檔案的位元組，並將其重新編寫為 ASCII 字串，使圖片能夠內嵌於程式碼中傳輸，而不必作為獨立檔案。編碼後的文字遵循 RFC 4648 中定義的標準，該標準規定了 Base64 字元集、填補規則與字元集合。當字串以 MIME 類型加上 data: 標記作為前綴時，結果稱為資料 URL（data URL），瀏覽器可以直接透過 <img> 標籤、CSS 中的 background-image 或 HTML 電子郵件內文來呈現該圖片。典型的資料 URL 看起來像 data:image/png;base64,iVBORw0KGgo...，其中以分號分隔的 MIME 類型會告訴瀏覽器該使用哪個解碼器，而逗號則標示實際編碼位元組的起始位置。
只要圖片需要存在於單一檔案中，開發人員就會使用 Base64。CSS 樣式表可以內嵌一個小圖示，讓網頁不再需要第二個 HTTP 請求；JSON 設定檔可以帶著縮圖；HTML 電子郵件可以內嵌其標誌，因為大多數用戶端會封鎖外部圖片；JavaScript 套件則可以在真正的素材載入前預先載入一個佔位圖。權衡取捨很直接：Base64 會讓原始二進位資料膨脹大約 33%，因為三個輸入位元組會變成四個輸出字元，所以這個技術更適合小圖示、UI 字符（glyph）與預覽圖，而非全解析度的照片。
圖片轉 Base64 轉換器的功能
Image to Base64 Converter 會讀取本機的圖片檔案，驗證實際的位元組（而不僅僅是副檔名），並產生純 Base64 字串或完整的資料 URL。由於轉換器會檢查原始檔案內容，資料 URL 中回報的 MIME 類型會與位元組實際內容相符，這能避免一個常見的錯誤：把 JPEG 的內容貼上卻帶著 image/png 前綴，導致圖片破圖。該工具還會回報解碼後的像素尺寸、以位元組為單位的檔案大小，以及圖片的預覽，讓你在複製任何內容到專案之前，可以確認是否載入了正確的檔案。所有處理都在你的瀏器分頁中進行，因此原始圖片從未離開你的電腦。
一步步將圖片轉換成 Base64
- 開啟 Image to Base64 Converter 並點擊檔案選擇器，從電腦中選擇一個 PNG、JPEG、GIF 或 WebP 檔案。
- 選擇輸出模式：若你只需要編碼後的字串，請選擇純 Base64；如果你想要可直接貼上的
data:image/...;base64,...格式，請選擇圖片資料 URL。 - 觸發轉換並等待工具顯示偵測到的位元組格式、解碼後的像素尺寸、檔案大小以及螢幕上的預覽。
- 確認 MIME 類型與尺寸符合你預期載入的檔案。這是抓出錯誤檔案、被重新命名的副檔名或損壞上傳的時機。
- 使用複製按鈕複製完整的輸出內容。如果你選擇的是資料 URL，MIME 前綴會從已驗證的圖片位元組取得，因此你可以將該字串直接貼入
img標籤或 CSS 規則中。
純 Base64 vs. 資料 URL：何時該使用哪一種
這兩種輸出模式適用於不同的工作，選錯通常代表之後必須手動加上或移除前綴。純 Base64 只是沒有任何外圍標記的編碼字元。你可以在 JavaScript 變數、API 酬載、資料庫 blob，或任何解碼端已經知道將接收何種檔案類型的情境中使用它。資料 URL 則會將該字串包入 data 結構描述、MIME 類型以及 ;base64 標記，產生一個瀏覽器無需任何額外資訊就能呈現的自描述值。
| 面向 | 純 Base64 | 圖片資料 URL |
|---|---|---|
| 格式 | 僅有編碼後的 ASCII 字元 | 前綴加上編碼後的字元 |
| 典型用途 | API、資料庫、JSON 設定 | HTML img 標籤、CSS、電子郵件範本 |
| 是否可直接由瀏覽器呈現 | 否，需要包裝 | 是，自描述 |
| 輸出中是否包含 MIME 類型 | 不包含 | 包含，取自已驗證的位元組 |
| 最適用於 | 程式化處理 | 直接顯示使用 |
如果你要在 CSS 內嵌入小圖示，資料 URL 形式幾乎永遠是你想要的選擇。如果你打算將編碼後的字串傳送到會把它寫回磁碟的伺服器端點，純 Base64 能讓酬載保持乾淨。
為什麼 MIME 類型很重要
資料 URL 只有在前綴與後續的位元組相符時才有用。瀏覽器會根據該前綴來解碼酬載，所以給 PNG 資料貼上 image/jpeg 標籤，會產生破圖或靜默失敗。許多檔案系統會用 .jpg 這類副檔名隱藏真相（在內部其實是被重新命名的 PNG），作業系統層級的預覽也可能與實際位元組不一致。透過檢查檔案的魔術數字（magic number）而非檔名，轉換器能保證你複製的資料 URL 第一次就能正確顯示。同樣的道理也是為什麼 MDN 關於資料 URL 的文件中，會特別強調 MIME 類型必須與酬載對應。
解碼後的真實尺寸與大小
Base64 是一種可逆的編碼，所以解碼後的酬載與原始檔案逐位元組完全相同。因此解碼後的像素尺寸會與你的圖片檢視器所顯示的一致，解碼後的位元組數量則等於磁碟上的檔案大小，再加上編碼字元集的額外負擔。當轉換器顯示解碼後的度、高度與大小時，這些數字來自產生 Base64 字串的同一批位元組，這代表你可以把它們當作下游決策（例如 CSS 大小或 API 酬載限制）的可靠依據。如果專案預算限制內嵌圖片最多只能 20 KB，轉換後檢查解碼大小是唯一能確認符合該限制的方式。
Base64 圖片最適合用在哪些地方
當目標是減少來回請求，或是遞送一個自包含的檔案時，Base64 就能發揮所長。常見的效益包括：使用資料 URL 直接在 HTML 中嵌入 favicon；在電子郵件簽名中附加小標誌，讓它在封鎖遠端圖片的用戶端中仍能顯示；將載入骨架（loading skeleton）內嵌於單一檔案的 HTML 展示中；將縮圖存入 JSON 記錄裡，讓 API 回應同時帶著中繼資料與預圖。但這個技術不適合大型照片，因為 33% 的額外負擔與失去 HTTP 快取的缺點，很快就會蓋過便利性。針對這類情況，改用一般託管的檔案，並搭配 Image Compressor 或 Image Resizer 會是更好的做法。
需要留意的實際限制
Base64 字串大約會膨脹三分之一，所以一個 90 KB 的 PNG 會變成大約 120 KB 的 ASCII。相同的膨脹也會套用於資料 URL 的外層包裝，而許多伺服器、CDN 與電子郵件用戶端對 URL 長度與內嵌酬載大小都有實際的限制。大多數瀏器在 CSS 中能容忍數 MB 的資料 URL，但行動版電子郵件用戶端經常會把字串截斷到遠低於該長度。一個實用的經驗法則是：當酬載會透過電子郵件或較舊的網頁框架傳遞時，將編碼後的圖片控制在 10 KB 以內。關於何時該使用 JPG 或 PNG 的指南是個很好的延伸閱讀，因為選擇較小的來源格式能讓 Base64 輸出保持在可控的大小。
反方向操作：將 Base64 還原為圖片
如果你已經有 Base64 字串並需要再次取得檔案，反向工具是 Base64 to Image Converter。它接受嚴格的 Base64 字串或完整的資料 URL，會根據支援的圖片格式驗證酬載，並讓你下載乾淨的 PNG、JPEG、GIF 或 WebP。這種往返轉換在以下情境很實用：從 CSS 檔案中還原嵌入的圖片、檢查從網路請求中擷取到的酬載，或在專案成長後把內嵌素材遷移為獨立檔案。
統整上述內容
對大多數日常工作來說，工作流程很短：選擇檔案、選擇純 Base64 或資料 URL、複製輸出、貼到該去的地方。在把字串提交到版本控制之前，先在螢幕上驗證 MIME 類型與尺寸，並記得 Base64 只是編碼，不是壓縮。如果編碼後的字串對該情境來說太大，通常比較好的做法是先使用 Image Compressor 縮小來源圖片，或使用 WebP Converter 轉成更有效率的格式，然後再重新編碼。針對像是從同一個來源檔案產生 favicon 等相關任務，favicon 產生指南會在同樣的全瀏覽器工作流程中介紹下一步。
如果你正在權衡各種選項，Remove EXIF Data from Photos in Your Browser 對此有詳細說明。
如果你正在權衡各種選項，Add a Solid Background to Any GIF in Your Browser 對此有詳細說明。