Image to Base64 轉換器會在您的瀏覽器中，一次將一個已驗證的 PNG、JPEG、GIF 或 WebP 檔案轉換為 RFC 4648 Base64 或完整的 data URL，並依據已驗證的位元組而非檔名來選擇 data URL 的 MIME 類型。這種單檔處理方式也是處理「大量」或「多張圖片」任務最安全的方法。每個檔案都會在目前的分頁中完成讀取、結構驗證、解碼與編碼;不會上傳至 Lizely 或任何外部轉換服務。瀏覽器一次只需在記憶體中保留一張圖片，因此同一個工具能輕鬆處理一長串小圖示、數十個測試樣本，或依序處理的混合 PNG 與 JPEG 照片資料夾。對於 N 個檔案的批次，實際的工作流程就是簡單地執行轉換器 N 次——選擇、轉換、檢查、複製——然後再處理下一個。世代計數器與 ObjectURL 撤銷機制可確保較早檔案的緩慢讀取不會洩漏到較晚的結果，而選擇新檔案或切換輸出模式會立即清除先前的預覽、輸出、錯誤、忙碌狀態與複製狀態。

image to base64 bulk multiple images
Image to Base64 大量轉換:在本機轉換多個檔案

本機單檔轉換器中「大量」的含義

「大量」這個詞片被寬鬆地用於任何涉及多張圖片的任務。在伺服器端工具中，這通常代表拖放至佇列、單次網路往返，以及一個合併的結果。Image to Base64 轉換器並非以這種方式運作，而且差異是刻意的。單檔迴圈對批次工作有三項具體優勢:

  • 不上傳代表沒有共享的隱私介面。每個檔案從選擇器到剪貼簿都停留在您的瀏覽器分頁中，因此內部截圖、草稿或未發佈的素材絕不會離開本機。
  • 嚴格的逐檔驗證代表單一損毀或不完整的檔案無法污染其餘批次。轉換器會在產生任何輸出之前以明確的錯誤訊息拒絕該檔案，您只需繼續處理下一個檔案。
  • 世代保護的狀態代表檔案 3 的緩慢讀取無法覆寫檔案 7 已複製的結果。您看到的輸出永遠屬於您最近選擇的檔案。

對於大多數「大量」需求——建構 JSON 樣本、為離線原型打包圖示、為電子郵件範本產生內嵌圖形——逐檔迴圈的速度已足夠快，相較於您保留的隱私與驗證保證，真正的批次 API 所節省的往返時間可忽略不計。

如何將多張圖片轉換為 Base64

對於批次中的每張圖片，工作流程完全相同。重複執行是處理多個檔案的建議方式。

  1. 在瀏覽器中開啟 Image to Base64 轉換器。
  2. 點擊檔案選擇器並選擇一個 PNG、JPEG、GIF 或 WebP 檔案。確認所選檔案未超過 5 MiB (5,242,880 位元組) 的限制;工具會在讀取內容之前拒絕過大的檔案。
  3. 使用可見的控制項選擇輸出模式——純 Base64 或完整的 data URL。純模式僅回傳具有適當填補的標準 RFC 4648 字元集;data URL 模式會在輸出前加上位元組偵測器實際找到的 MIME 類型。
  4. 執行轉換。元件會讀取檔案、驗證結構容器、透過 createImageBitmap 要求瀏覽器進行解碼(若該 API 不可用則改用 HTMLImageElement 後備方案)，並回報偵測到的格式、實際解碼後的尺寸、檔案大小與預覽。
  5. 檢查預覽與偵測到的中繼資料。若尺寸、大小或預覽與您預期的不同，請勿複製——改為選擇其他檔案。
  6. 使用複製控制項複製完整輸出。若剪貼簿權限被拒絕，請手動選擇並複製可見的文字;若不會發生失敗的動作，轉換器會將輸出保留在原處，而不是將其隱藏。
  7. 將該字串貼到您的目標文件——JSON、HTML、CSS、Markdown 樣本或電子郵件範本——然後返回步驟 2 處理下一個檔案。選擇新檔案會立即清除先前的預覽、輸出、錯誤、忙碌狀態與複製狀態。

批次的總時間會依檔案數量與逐檔大小線性增加。由於頁面從不上傳，您僅受限於瀏覽器在本機解碼每個檔案的速度;沒有網路瓶頸。

轉換器對每個檔案的檢查項目

由於轉換器會忽略檔名、檔案選擇器的接受篩選條件，以及作業系統提供的 MIME 字串，因此必須從位元組本身重建對格式的信任。結構偵測器與配對的 Base64 to Image 工具共用，其檢查項目具體到足以彙整說明。

格式必要的結構證據
PNG完整的八位元組簽章、格式正確的第一個 IHDR chunk、結尾的 IEND 邊界
JPEGSOI 標記後接另一個標記，以及結尾的 EOI
GIFGIF87a 或 GIF89a 標頭、完整的邏輯螢幕描述元、結尾的 trailer
WebPRIFF 長度與檔案大小完全相符、WEBP FourCC、有界的 VP8、VP8L 或 VP8X 第一個 chunk

僅有魔術數字或不完整的容器會被拒絕。在結構前檢查通過後，瀏覽器還必須能解碼該圖片並回報正整數尺寸，否則轉換器仍會回報失敗。偵測到的位元組格式會決定 data URL 前綴;將 PNG 重新命名為 photo.jpg 並宣告為 image/jpeg，仍會產生 data:image/png;base64,… 純模式會去除前綴，僅回傳標準的 Base64 字元。

適用於批次中每個檔案的限制

無論您編碼一張或五十張圖片，相同的逐檔限制皆適用。這對於「大量」工作來說很重要，因為較長的批次更容易觸及其中之一。

  • 檔案大小:正好 5 MiB (5,242,880 位元組)。該邊界值可接受;超出 1 個位元組會在讀取檔案主體之前被拒絕。讀取後會再次確認 ArrayBuffer 長度。
  • 該位元組預算的最大 Base64 長度:6,990,508 個字元，因為每三個輸入位元組會產生四個輸出字元，而 ceiling(5,242,880 / 3) × 4 = 1,747,627 × 4 = 6,990,508。加上最長的支援 data URL 前綴(data:image/webp;base64,, 23 個字元)，最大輸出預算正好為 6,990,508 + 23 = 6,990,531 個字元;下一個字元會被拒絕。不會發生靜默截斷。
  • 解碼後的尺寸:任一邊不得超過 20,000 像素，且總像素面積不得超過 40,000,000。解碼後的壓縮圖片可能比其檔案大小暗示的記憶體用量大得多，這些上限可保護分頁。
  • 格式範圍:僅支援 PNG、JPEG、GIF 與 WebP。即使瀏覽器或檔名將 SVG、AVIF、HEIC、BMP、TIFF、PDF 及任意文字視為圖片，這些也不在支援範圍內。

批次中單一過大或損毀的檔案會產生明確的錯誤且沒有部分結果;在後續檔案失敗後，轉換器絕不會在畫面上留下過時的成功輸出。

多個 Base64 字串的常見用途

一旦每個檔案完成編碼，這些字串即可與一般文字互換。這使逐檔迴圈適合用於:

  • API 酬載與 JSON 樣本，其中圖片欄位以字串而非 multipart 附件表示。
  • HTML 與 CSS 實驗，其中小的 data:image/...;base64,... 值可減少一次 HTTP 請求，並將資產保留在文件內部。
  • 電子郵件範本，這類範本通常會封鎖外部圖片 URL，僅接受以文字形式呈現的內嵌圖片。
  • 離線原型與單元測試，其中可重現的 Base64 樣本隨來源樹一起發布，完全不接觸網路。
  • 除錯流程，其中將圖片傾印為文字可方便在 diff 中並排比較兩個版本。

對於較大的資產——主視覺照片、全螢幕截圖，任何超過數百 KB 的內容——一般圖片 URL 仍然較小且快取效果更好。在加上任何 data URL 前綴之前，Base64 通常會使傳輸大小增加約三分之一，因此文字表示法最適合保留在明確需要文字的情境。

編碼前預先處理檔案的時機

由於轉換器會在 Base64 內容中保留原始圖片位元組，且不會重新調整大小、重新壓縮、改變顏色、壓平透明度或去除中繼資料，因此任何大小或品質的決定都必須在編碼前完成。

  • 若您的批次主要受檔案大小限制，請先讓每張圖片通過 Image Compressor，然後再編碼。較小的來源位元組會按比例產生較短的 Base64 字串，且能更穩定地保持在 5 MiB 上限內。
  • 若您需要新的尺寸，請先讓每個檔案通過 Image Resizer。轉換器不會為您靜默變更像素數量。
  • 若您的批次混合了具有誤導性副檔名的格式，位元組層級的偵測器就是您所需的保護。相關說明記載於 Image to Base64:從位元組偵測真實格式。

將步驟分開可避免隱藏的重新壓縮，並使每個編碼輸出可預測。即使內容保留在本機，仍應將未知的圖片視為不受信任的內容;瀏覽器成功解碼僅能驗證技術上的可讀性，無法驗證作者身分、真實性、無障礙性、著作權狀態、審核安全性，或是否含有隱藏資料。

延伸閱讀:在本機瀏覽器中執行的 Image to PDF 替代方案。