一款獨立、基於瀏器的 Base64 轉 Image 轉換器替代工具，全程在當前分頁內解碼 Base64 資料，將解碼後的位元組驗證為真正的 PNG、JPEG、GIF 或 WebP，並回傳一個副檔名與已驗證檔案簽章相符（而非與宣告的 MIME 類型相符）的下載檔案。嚴格的解碼器將 Base64 視為位元組編碼，而非可信賴的檔案標記，這意味著即使 data URL 標示為 image/jpeg，但實際內容卻是 PNG 位元組，仍會在儲存時取得正確的副檔名。每次轉換皆在本機執行：沒有上傳至 Lizely、不經外部轉換服務中繼，且工具關閉後不留存任何已解碼影像。本機處理、結構驗證與位元組保留三者結合，正是大多數讀者在搜尋可以真正信任、用來處理從 API 回應、JSON 欄位、電子郵件範本、瀏覽器儲存值或開發紀錄中複製而來之 Base64 資料的 Base64 to Image Converter 替代方案時，所期待的重點。

base64 to image converter alternative
Base64 to Image Converter 替代方案：嚴格且本機執行

讀者所說的「Base64 to Image Converter 替代方案」是什麼意思

搜尋這個詞彙的人，大多並非在尋找他們能找到的第一個轉換器。他們通常已經試過某個工具，並碰到下列特定類型的困擾：

  • 隱私與資料落地。轉換器將 Base64 傳送到遠端伺服器；當資料中包含內部儀表板的螢幕擷圖、客戶資料、未公開的 UI，或任何受機密政策規範的內容時，這是完全不可接受的。
  • 信任錯誤的 MIME 類型。許多工具照單全收 data URL 所宣告的媒體類型，即便位元組實際上是 PNG，仍存成 .jpg 檔案，產生下游檢視器無法開啟的誤導性產出物。
  • 靜默重寫輸入。其他轉換器會悄悄去除空白字元、將 URL 安全字元替換為標準字母集，或補上缺少的填補字元。這會掩蓋當初產生 Base64 的程式中的規範違規錯誤。
  • 儲存時重新編碼。部分轉換器透過 canvas 繪製預覽、縮放結果、重新壓縮，或移除中繼資料，從而破壞逐位元組還原原始產出物的能力。
  • 格式檢查薄弱。少數工具僅檢查前幾個魔術位元組，導致截斷的檔案或結構不完整的容器被視為成功轉換。

一個值得信賴的替代方案應同時解決上述所有問題：資料不離開瀏覽器、簽章偵測優先於宣告的 MIME、輸入採用嚴格驗證而非重寫、保留原始位元組，且格式檢查為結構性而非表面性的。

Base64 to Image Converter 的不同運作方式

這個 Base64 to Image Converter 採用一個確定性的處理流程，能清楚對應到上述痛點：

  • 純本機處理。解碼、簽章偵測、覽器影像驗證、預覽產生與下載，全部在當前分頁內執行。暫存物件 URL 會在被取代、驗證失敗，以及工具卸載時撤銷。
  • 嚴格的 RFC 4648 字母集。解碼器僅接受包含加號與斜線的標準字母集，要求長度可被 4 整除，僅允許在結尾出現一個或兩個填補字元，且不得有任何未使用的填補位元。空白、換行、URL 安全字元、缺少或多餘的填補字元，以及非標準的填補位元，將以明確錯誤拒絕，而非靜默正規化。
  • 基於簽章的格式偵測。工具讀取實際解碼後的位元組，而非信任 data URL 的 MIME 參數。PNG 須具備完整的 8 位元組簽章，加上 IHDR chunk 與結尾的 IEND 邊界。JPEG 須具備影像起始標記、其後的標記，以及影像結束位元組。GIF 須為 GIF87a 或 GIF89a、具備足夠的輯螢幕描述子位元組，以及串流結尾標記。WebP 須具備 RIFF 與 WEBP 標記、精確的 RIFF 位元組計數，以及一個有界限的 VP8、VP8L 或 VP8X 第一 chunk。
  • 瀏器端影像驗證。結構性預檢會拒絕裸露或截斷的魔術位元組，但這無法取代影像解碼。瀏覽器還必須透過 createImageBitmap 成功解碼完整的 Blob（僅在該 API 不可用時才以 HTMLImageElement 作為備援），並在任何預覽或下載發佈前回報真實的正向尺寸。
  • 保留位元組的下載。下載檔案包含原始解碼後的位元組。預覽的顯示尺寸僅為版面配置而受限，CSS 並不會縮放檔案。因此下載的 GIF 可保留動畫，PNG 可保留來源中既有的 alpha 與內嵌 chunk。

宣告的 MIME 類型（若存在）會被視為可忽略的中繼資料。一個標示為 image/jpeg 但內容為 PNG 位元組的 data URL，會被解碼、驗證為 PNG、以 PNG 預覽，並以 .png 副檔名下載。這種不一致正是此工具設計上要揭露而非隱藏的情境。

三步驟將 Base64 轉換為影像

  1. 貼上嚴格的 RFC 4648 Base64，或包含明確 ;base64 標記的 data URL至輸入欄位。純 Base64 無需前置詞；data URL 必須包含逗號分隔符，且末端恰好有一個 ;base64 標記，媒體類型須採用 type/subtype 語法，前置參數須採用 name=value 語法。
  2. 選擇「Convert to image」並讀取偵測到的格式、解碼後的尺寸、位元組大小，以及頁面上的預覽。若宣告的 MIME 與偵測到的簽章不一致，工具會將宣告值標示為已忽略，並以結構驗證勝出者為準。尺寸與位元組摘要指的是實際解碼後的資源，而非螢幕上的預框。
  3. 以下載來自已驗證檔案簽章所決定之副檔名（.png、.jpg、.gif 或 .webp）取得原始解碼位元組。位元組被精確保留，因此下游檢查工具看到的產出物與原始編碼內容一致。編輯輸入會立即移除先前的預覽、下載、狀態、錯誤與忙碌狀態，而開始另一次轉換會在執行新工作前先撤銷舊的物件 URL。

支援的輸入與被拒絕的內容

解碼器的接受範圍刻意很窄。下表摘要說明其接受與拒絕的內容，以及每項拒絕的原因。

輸入形式接受拒絕
純 Base64嚴格的 RFC 4648 字母集、長度可被 4 整除、僅在必要時使用結尾填補、零個未使用的填補位元空白、換行、URL 安全的 - 與 _、缺少或多餘的填補字元、非標準的填補位元
Data URLtype/subtype、;base64 前的 name=value 參數、恰好一個末端 ;base64 標記、逗號分隔符百分比編碼的資料、重複的 ;base64 標記、;base64 之後的參數、非 Base64 的 data URL
容器位元組PNG 簽章 + IHDR + IEND、JPEG SOI + marker + EOI、GIF87a/GIF89a + 輯螢幕 + 結尾標記、RIFF + WEBP 搭配有界限的 VP8 chunk裸露的魔術位元組、截斷的串流、RIFF 位元組計數不符、未定義的第一 chunk

若您的來源提供包裝過的 MIME Base64 或 Base64url，請於來源端或使用專門的文字工具先行正規化，再進行轉換；本工具不會靜默重寫輸入。底層規則記載於 RFC 4648 中（涵蓋字母集與填補），而 data URL 的結構則由剖析器所使用的相同 RFC 2397 文法描述。

應事先掌握的明確限制

此合約提供的是精確數字，而非含糊的「大檔案」說法，讓您能在貼上之前預先確認資料是否符合。

限制數值
輸入長度8,000,000 個 UTF-16 碼元
解碼後位元組上限5,242,880 位元組 (5 MiB)
最大邊長20,000 像素
最大總像素數40,000,000

位元組與輸入限制之間的關聯是可預期的。Base64 將 3 個位元組展開為 4 個字元，因此最大的解碼後資料量 5,242,880 位元組，大約對應於：

5,242,880 位元組 × (4 個 Base64 字元 / 3 個位元組) = 6,990,506.67

向上取整至最接近的 4 字元群組，並依 5,242,880 mod 3 = 2 所需之末端填補進行調整後，可容納於解碼後上限內的最大純 Base64 資料量為 6,990,508 字元，低於 8,000,000 字元的輸入上限。帶有 data:image/...;base64，前綴的 data URL，其可用資料量會扣除該前綴長度，因此實際限制取決於兩者中先觸及者。工具會在配置位元組陣列前計算預期輸出大小，接受剛好等於上限的內容，並拒絕超出上限一個位元組的內容。經瀏覽器解碼後，寬度與高度皆須為正，任一邊長不得超過 20,000 像素，且乘積須維持在 40,000,000 像素以內。這些尺寸上限是為了保護瀏覽器記憶體，因為編碼精簡的檔案仍可能展開為龐大的像素表面。

何時需要下一步處理

此轉換器保留原始位元組，對於檢查、還原、除錯以及已編碼資料的交接而言是正確的行為，但若您想變更影像本身，則並非合適的工具。請在以下情境使用對應的同類工具：

  • 預覽成功但檔案比預期大。請先下載，再使用 Image Compressor 在瀏覽器中縮小 JPG、PNG 或 WebP 的大小。
  • 尺寸不符合目標用途。請於 Image Resizer 中開啟下載的檔案，設定精確的像素尺寸。
  • 您的原始資料為任意文字 Base64 而非影像。請改用通用的文字 Base64 工具。本轉換器專注於影像工作流程，以維持檔案簽章規則的可預測性。
  • 您也想檢視轉換後檔案中所含的 JPEG 擷取中繼資料。下載後，請於 EXIF Viewer 中開啟，在本機讀取相機、鏡頭、方向與 GPS 等欄位。

就一般的網站發布而言，建議將影像儲存為實體檔案，並以合適的 URL 引用，而非重新嵌入 Base64；Base64 會增加傳輸量，通常不是遞送大型影像最有效率的方式。對於敏感性內容，即便轉換過程本身仍於本機執行，也應避免將其貼入共用裝置。請以對待未知下載檔案相同的謹慎態度處理未知影像資料，因為瀏覽器解碼並非惡意程式分析、內容審核、隱寫術偵測，也無法保證該影像安全或真實。

相關閱讀：如何從本機檔案取得網站圖示影像。

相關閱讀：Image Color Picker 替代方案：免費、私密、本機執行。