Base64 轉圖片轉換器是純瀏覽器端的解碼器，可將一段嚴格的 RFC 4648 Base64 承載內容，或一段以 ;base64 結尾的 RFC 2397 data URL，轉成具有正確副檔名的已驗證 PNG、JPEG、GIF 或 WebP 檔案。即使搜尋查詢寫著「批次」或「多張圖片」，此工具每次轉換仍只處理一段承載內容:它會驗證字元集與填補字元、解碼位元組、對容器執行結構預檢(PNG 的 IHDR/IEND、JPEG 的 SOI/EOI、GIF 的 logical-screen/trailer，或 WebP 的 RIFF/VP8 系列)，然後才請瀏覽器實際解碼圖片，再顯示預覽或啟用下載。若要處理多段 Base64 字串，可在同一個分頁中依序執行多次轉換(貼上、轉換、下載、重複)，或在多個瀏覽器分頁中平行執行。每次下載的都是原始解碼位元組，副檔名依據真實檔案簽章決定，而非依據所宣告的 MIME，因此即使是 data:image/jpeg;base64，前綴實際包裹 PNG 位元組時，仍會產生 .png 檔。所有步驟皆在本機執行，不會上傳，暫存物件 URL 在被取代時會撤銷。
為何「批次」Base64 解碼一次只能處理一段轉換
此工具刻意設計為單承載內容解碼器。每次轉換都會嚴格驗證 RFC 4648 字元集、完整預檢容器結構，並透過瀏覽器的圖片管線實際解碼，才會顯示任何預覽或下載。若要將多段承載內容捆綁成一次批次執行，就得猜測字串的結尾與下一段字串的開頭，或放寬嚴格的字元集限制——這兩種做法都與此工具的設計理念不符。以下幾個具體原因說明了單承載內容的設計:
- 嚴格的字元集與填補字元檢查必須知道字串的結尾。若沒有明確的分隔符號，兩段連在一起的合法 Base64 字串會被視為一段更長的字串，進而破壞四字元分組規則，或悄悄產生損毀的檔案。
- 格式偵測是根據解碼後串流的前幾個位元組。面對批次輸入，解碼器必須在一段合併的緩衝區中反覆掃描 PNG、JPEG、GIF 或 WebP 的簽章。
- 解碼後位元組上限 5,242,880 位元組(正好 5 MiB)會在前置階段強制執行，而每張圖片的尺寸上限(每邊 20,000 像素，總計 40,000,000 像素)則在瀏覽器解碼後檢查。批次執行需要同時設定每張圖片的上限與總合上限，這些限制在這個工具中都不存在。
- 每次轉換會撤銷先前的物件 URL，並以非同步產生計數器追蹤。若在一個輸入中執行多次解碼，則需要獨立的生命週期管理，而這是本工具未實作的功能。
因此，對「批次」與「多張圖片」的務實答案就是「多次單一轉換，由您依序或平行執行」。此工具的嚴格性正是讓工作流程可靠而非礙事的特色。
工具接受的輸入——以及會拒絕的內容
解碼器接受嚴格的 RFC 4648 Base64(字元集 A–Z a–z 0–9 + /，僅在必要時於結尾使用 = 填補)，或接受帶有恰好一個結尾 ;base64 標記與逗號分隔符的 RFC 2397 data URL。基於「產生端的輸出若為規範格式即可，否則應大聲失敗」的假設，它刻意拒絕以下輸入:
- 任何空白字元——字串中任何位置的空格、Tab、換行或歸位字元。
- 換行換欄或欄位格式化的 Base64，包括某些 MIME 編碼器加入的 76 字元換行。
- URL 安全字元(- 與 _)、缺漏的填補字元、位置錯誤的填補字元、多餘的 = 字元，或長度非 4 的倍數的字串。
- 最後一個四位元組內部非零的未使用填補位元，這代表產生端剝除了資料或使用了非規範的編碼器。
- 在 ;base64 之後帶有參數、base64 標記重複、百分比編碼承載內容，或任何不符合 type/subtype 加 name=value 語法的 data URL。
無論輸入形式為何，皆適用以下三項硬性上限:
| 限制 | 數值 |
|---|---|
| 輸入字元數 | 8,000,000 個 UTF-16 碼元 |
| 解碼後位元組 | 5,242,880 位元組(正好 5 MiB) |
| 最大寬度或高度 | 20,000 像素 |
| 最大像素面積 | 40,000,000 像素 |
| 支援格式 | PNG、JPEG、GIF、WebP |
若您的資料源會產生 MIME 包裝或 Base64url 輸出，請在資料源端將其正規化——本工具會回報錯誤，而不是默默重寫位元組。一個實用的健全性檢查:一段剛好 4,000,000 字元、無填補字元(長度為 4 的倍數)的 Base64 字串，解碼後為 4,000,000 × 3 / 4 = 3,000,000 位元組，完全低於 5,242,880 位元組的上限。當輸入為規範格式但承載內容對本解碼器而言過大時，從過大的 Base64 圖片回復真實檔案的指南介紹了其他替代方案。
將多段 Base64 字串轉為圖片檔案
將多段 Base64 承載內容轉為真實圖片檔案的直接工作流程，是在單一工作階段中依序處理，並可在每次轉換互不影響時，選擇性地以分頁平行處理。
- 在瀏覽器中開啟 Base64 to Image Converter。
- 將第一段 Base64 承載內容——可以是純 RFC 4648 字串，也可以是帶有明確 ;base64 標記的 data URL——複製到輸入區。
- 選擇Convert to image，等待預覽、偵測到的格式、解碼後的尺寸與位元組數出現。
- 使用工具依據解碼後位元組真實檔案簽章所選的副檔名(PNG、JPEG、GIF 或 WebP)下載檔案。
- 清除輸入內容並貼上下一段承載內容。先前的預覽、下載連結及任何物件 URL 都會自動撤銷，因此遺留狀態不會洩漏到下一次轉換。
- 對其餘每段承載內容重複此流程。同一分頁會一次處理一段，各循環之間不會相互污染。
- 若要平行處理承載內容，可複製分頁並同時執行轉換。每個分頁獨立運行各自的解碼器，彼此之間不共享任何資料。
由於每次轉換都會撤銷先前的物件 URL，並以產生計數器處理非同步工作，較舊承載內容的慢速解碼不會覆寫來自新貼上新內容的目前狀態。編輯輸入內容也會立即清除任何先前的預覽。
解碼器如何決定檔案格式
下載副檔名絕不會取自 data URL 宣告的 MIME 類型。解碼器將該 MIME 視為不受信任的中繼資料，改為檢查解碼後容器的前幾個位元組。它可辨識的四種簽章如下:
| 格式 | 辨識位元組 / 邊界 | 檢查 |
|---|---|---|
| PNG | 8 位元組簽章、第一個 IHHR 區塊、結尾 IEND | 完整結構預檢 |
| JPEG | 影像開頭、下一個標記、影像結尾 | 僅必要邊界 |
| GIF | GIF87a 或 GIF89a、邏輯螢幕描述子、trailer | 僅必要邊界 |
| WebP | RIFF 標頭、WEBP 標記、精確位元組計數、有邊界的 VP8 / VP8L / VP8X 第一個區塊 | 大小一致 |
當宣告的 MIME 與實際位元組不一致時——例如 data:image/jpeg;base64,… 實際包裹的是 PNG 位元組——工具會將宣告的 MIME 顯示為「已忽略」，驗證真實的 PNG 結構，並下載為 .png。這能避免產生副檔名來自不受信任中繼資料的檔案，這是手寫編碼器常見的失敗模式。完全不帶 data: 前綴的純 Base64 輸入會經過相同的檔案簽章偵測，運作方式完全一致。
預檢能抓出裸魔術位元組與截斷的串流，但無法取代實際解碼。解碼後的 Blob 還必須透過 createImageBitmap 載入(若該 API 不存在則改用 HTMLImageElement 後備方案)，且寬度與高度必須為符合尺寸限制的正整數。通過預檢但瀏覽器解碼失敗的容器，會被視為損毀圖片而拒絕，不會作為成功轉換輸出。
批次 Base64 字串的真實工作流程
批次的性質決定適合的工作流程。對於五到二十段、每段低於 5 MiB 的承載內容，在單一分頁中依序轉換是操作上最快的做法:每個循環只需數秒，工具會自動撤銷先前的狀態。對於多段較大的承載內容同時處理，請為每段承載內容在獨立分頁中開啟 Base64 to Image Converter 並平行執行——這裡的關鍵限制是瀏覽器的記憶體，而非伺服器負載。
當批次以單一文字檔形式送達、內含多段 Base64 字串時，請自行使用文字編輯器或指令稿自行分割。解碼器並未內建分割器，因為可靠的分割需要每個編碼器都必須產生的分隔符號，而這類分隔符號並非 RFC 4648 字元集的一部分。對於內嵌於 API 回應、JSON 文件或電子郵件範本中的承載內容，請將每段承載內容逐一複製到輸入區。嚴格的字元集檢查能立即告訴您，產生端產生的是否為規範的傳輸資料，或者是否洩漏了 URL 安全字元、換行或空白字元。
一旦解碼後的檔案存到磁碟，更廣泛的批次圖片作業便會移轉至其他工具。將多張圖片合併為一張圖片:選擇版面配置指南說明了如何將解碼後的檔案組合成格狀或條狀版面以便交付。
After You Have the Image File
The download preserves the original decoded bytes. No canvas redraw happens, no resize, no recompression, no metadata stripping. A PNG keeps its alpha channel and embedded chunks, and a GIF keeps its animation. The on-screen preview is visually constrained only for page layout, never for the saved file — CSS does not resize the downloaded bytes.
Common next steps once the files are on disk:
- The image is too large to share: open Image Compressor to shrink a JPEG, PNG, or WebP after the fact.
- You need different dimensions: Image Resizer outputs an exact-pixel PNG from the decoded file.
- You need the bytes back as Base64 again: Image to Base64 Converter re-encodes the file using strict RFC 4648 or an accurate data URL.
Because the conversion never modified the pixels, you can also hand the file to any external tool — Photoshop, an image viewer, a CDN upload — without worrying about a hidden recompression step having changed colour depth or stripped animation. The tool does not repair corrupt files, optimise file size, or change format; for those tasks, take the verified bytes and run them through the appropriate dedicated converter.
For inspection, debugging, recovery, and handoff of images that already live in API responses, JSON fields, clipboard snippets, browser storage values, or development logs, the Base64 to Image Converter is a predictable single-payload tool. The "bulk" and "multiple images" use cases are answered by running it sequentially or in parallel across tabs, with strict alphabet validation that tells you whether each input is canonical transport data. To start a batch, open the Base64 to Image Converter and paste your first payload.