將影像轉換為 Base64 字串，意味著將其原始位元組編碼為 RFC 4648 所定義的 64 字元 ASCII 字母表，產生一個純文字區塊，該區塊可在 API 酬載、CSS 規則、電子郵件範本或 JSON 測試資料中代表原始檔案。轉換過程每使用三個輸入位元組就會產生四個輸出字元，這就是為什麼在加入任何資料 URL 前綴之前，所產生的 Base64 字串大約會比來源影像大三分之一。使用像 Image to Base64 Converter 這類本機瀏覽器型編碼器時，你可以挑選單一的 PNG、JPEG、GIF 或 WebP 檔案，在純字串與完整的 data: URL 之間做選擇，並從同一個分頁讀取經驗證過的輸出結果。檔案會被讀取、驗證並編碼，而無需傳輸到遠端伺服器，因此即使來源影像包含機密螢幕擷圖、未公開的產品圖片或內部文件，轉換過程仍能保持隱私。

how to convert image to base64 string
Image to Base64: Detect the Real Format from Bytes

Image to Base64 Converter 的功能

Image to Base64 Converter 會讀取單一本機影像檔，將其驗證為完整的 PNG、JPEG、GIF 或 WebP 容器，然後將原始位元組輸出為符合 RFC 4648 規範的 Base64 字串。過程中不會上傳任何資料;每一個讀取、解碼與編碼步驟都在當前的瀏覽器分頁中執行。此轉換器提供兩種輸出模式，可涵蓋大多數實際需求:一種是僅由標準字元與填補字元組成的純 Base64 字串;另一種是完整的資料 URL，帶有正確的 MIME 類型前綴，可直接放入 HTML、CSS 或 JSON 中使用。

此工具不信任作業系統所回報的檔名或 MIME 字串。取而代之的是，結構偵測器會檢查實際的位元組，驗證其所宣稱格式的容器邊界，並在顯示任何輸出之前強制瀏覽器本身解碼該影像。因此，被重新命名為 photo.jpg 的 PNG，或是標頭損毀的 JPEG，都無法產生誤導性的成功結果。資料 URL 中的 MIME 永遠來自位元組的真實內容，而不是檔案的命名。瀏覽器成功解碼只能確認這些位元組構成了一個技術上可讀的容器;它並不保證影像的著作權歸屬、可存取性、版權狀態、審核安全性，或是否未藏有隱匿資料，因此應將不受信任的影像視為需要驗證的輸入，而不是可信賴的內容。

如何將影像轉換為 Base64 字串

  1. 在瀏覽器中開啟 Image to Base64 Converter。
  2. 使用檔案選擇器，從你的電腦中挑選一個 PNG、JPEG、GIF 或 WebP 檔案。
  3. 選擇你要的是純 Base64 輸出，還是完整的影像資料 URL。
  4. 執行轉換;此工具會顯示偵測到的位元組格式、解碼後的尺寸、檔案大小，以及影像的預覽。
  5. 確認預覽與你的檔案相符，然後將完整輸出複製到剪貼簿。

對於數百 KB 以下的檔案，整個流程在數秒內即可完成，因為編碼器以三位元組對齊的區塊運作，絕不會透過單一可變參數呼叫洩漏出好幾 MB 的緩衝區。輸入在 5 MiB 上限以內時，會產生完整輸出且不會截斷。驗證失敗的檔案會回報具體原因——不支援的容器、瀏覽器解碼失敗、尺寸過大，或輸出長度超出預算——並清除先前的任何結果，以免不小心複製到過時的字串。

純 Base64 與資料 URL 輸出的比較

兩種輸出模式使用相同的 RFC 4648 字母表與填補規則，因此底層位元組完全相同。差異僅在於包圍它們的內容。

比較面向 純 Base64 資料 URL
開頭為 標準 Base64 字元 (A–Z、a–z、0–9、+、/)，加上 0–2 個尾端的 "=" 填補字元 data:image/<type>;base64，後接相同的酬載
MIME 類型 不包含 從實際的影像位元組偵測
典型用途 自訂 API、JSON 測試資料、資料庫欄位，或任何你的程式碼已知格式之處 HTML <img src>、CSS background-image、README 預覽，或任何期望使用自包含字串的消費者
新增的前綴長度 0 字元 PNG 與 GIF 為 22 字元，JPEG 與 WebP 為 23 字元
最大輸出 6,990,508 字元 6,990,531 字元

如果還不確定該選哪一種，建議從資料 URL 模式開始:這是最具可攜性的形式，當貼到瀏覽器網址列或 Markdown 文件中時，都能正確顯示。當你的應用程式會自行建構前綴，或是將字串儲存在期望原始編碼位元組的欄位時，則改用純 Base64。

檔案大小、尺寸與格式限制

此轉換器刻意採取嚴格做法。每個限制都會精確地在文件記載的邊界上檢查，超過一個單位的下一個值會以明確的錯誤訊息拒絕，而不是被默默地截斷。

限制 精確數值 存在的原因
最大輸入檔案大小 5,242,880 位元組 (5 MiB) 限制瀏覽器記憶體用量，並保持編碼的確定性
最大 Base64 長度 6,990,508 字元 依據 RFC 4648 的 4:3 膨脹率，由位元組預算衍生
最大資料 URL 長度 6,990,531 字元 最長支援的 data: 前綴 (JPEG 或 WebP 為 23 字元) 加上 Base64 預算
最大邊長尺寸 每邊 20,000 像素 防止小檔案膨脹成好幾 GB 的解碼後點陣圖
最大總面積 40,000,000 像素 攔截僅通過邊長檢查的寬幅全景圖或高聳海報
支援的容器 PNG、JPEG、GIF、WebP 每種格式皆具備完整驗證過的結構偵測器，加上瀏覽器解碼

輸入預算與輸出預算之間的關係，是 RFC 4648 所衍生的固定數學結果。5,242,880 位元組的輸入邊界會在純 Base64 模式下產生 6,990,508 字元的上限;而最長支援的資料 URL 前綴為 23 字元 (data:image/jpeg;base64，與 data:image/webp;base64,)，兩者加總便構成轉換器所強制執行的 6,990,531 字元輸出上限。兩個邊界都會精確檢查:剛好等於該大小會被接受，超過一個位元組則會在讀取主體前就被拒絕，接著再次驗證所產生的 ArrayBuffer 長度，因此不會發生默默截斷的情況。

MIME 類型在實務上是如何決定的

由於檔名、檔案選擇器的 accept 過濾條件，以及作業系統所提供的 MIME 字串，皆被視為不可信的提示，轉換器對每個檔案都會遵循固定的處理流程。它會先讀取位元組，接著請結構偵測器確認該位元組所顯示格式的完整容器邊界，最後將位元組交給瀏覽器本身，並要求其解碼成功且具有正的尺寸。唯有在這三層皆通過之後，才會顯示任何結果;而僅有魔數位元組但缺少完整容器的情況，會在瀏覽器解碼執行前就被拒絕。

具體而言，有四種情況值得了解:

  • 儲存為 photo.jpg 的真實 PNG仍會產生 data:image/png;base64,...，因為其八位元組簽章、IHDR 區塊與 IEND 邊界皆符合 PNG 模式。
  • 重新命名為 animation.gif 的真實 WebP仍會產生 data:image/webp;base64,...，前提是 RIFF 長度、WEBP FourCC，以及第一個 VP8、VP8L 或 VP8X 區塊皆吻合。
  • 主體被截斷的 JPEG——例如，在 EOI 標記之前就被截斷的下載檔案——會在結構偵測階段失敗，並回傳明確的錯誤，而不是產生部分輸出。
  • 標頭看似已知格式但無法解碼的情況——例如，偽裝成影像的 SVG——即便其前幾個位元組與四種支援容器中的某一種共用，仍會在瀏覽器解碼步驟失敗。

正是這種分層檢查機制，讓轉換器能夠有信心地標示影像的 MIME。一個命名為 photo.jpg、且被作業系統宣告為 image/jpeg 的 PNG，仍會產生 data:image/png;base64,，因為重要的是位元組實際包含的內容，而非任何人所聲稱的內容。

將影像編碼為 Base64 時常見的錯誤

大多數失敗的轉換都來自以下四個可預測的環節之一:

  • 輕信檔名。名為 photo.png 的檔案，實際上可能是被重新命名的 WebP。轉換器會忽略檔名與宣告的 MIME，接著檢查位元組與瀏覽器解碼結果。若兩者不一致，工具會回傳錯誤，而不是產生錯誤的 MIME。
  • 超過 5 MiB 輸入上限。從相機直接輸出的 JPEG 通常會超過此大小。如果需要在不更改尺寸的情況下縮減至位元組預算內，可先將檔案送至 Image Compressor 處理。
  • 預期會產生 canvas 樣式的副作用。此編碼器絕不會調整大小、重新壓縮、壓平透明度，或去除 metadata。Base64 酬載會精確地代表已驗證的檔案位元組，而頁面上的預覽大小僅為顯示上的限制。動畫 GIF 與 WebP 位元組在支援的消費者端仍會保持動畫。
  • 嘗試使用不支援的格式。SVG、AVIF、HEIC、BMP、TIFF 與 PDF 皆刻意排除在外，即使作業系統將其標示為影像。請使用專屬的轉換器，先將檔案轉為四種支援的容器之一，再進行編碼。

世代守衛與過時結果防範

幾項細微的行為讓此工具在你中途改變主意時依然可靠。每一次的檔案讀取與瀏覽器解碼皆隸屬於一個世代計數器，因此較舊檔案的延遲完成結果無法覆蓋較新的選取。更換另一個檔案，或切換輸出格式時，會立即移除先前的預覽、輸出、錯誤、忙碌狀態與複製狀態。臨時的 ObjectURL 會在替換時、驗證失敗時、格式變更時，以及元件卸載時被撤銷，因此舊的影像 Blob 不會洩漏記憶體或在頁面上徘徊。剪貼簿的寫入同樣受到世代守衛:舊的剪貼簿 Promise 無法在結果變更後發布誤導性的「已複製」狀態;而剪貼簿拒絕時，僅會讓可見的輸出保持可供手動選取與複製的狀態。

When Base64 Makes Sense (and When It Does Not)

Base64 是二進位位元組的文字表示法，而非壓縮格式。每三個輸入位元組會變成四個輸出字元，因此編碼後的承載量在加上任何 data URL 前綴之前，大約比來源圖片大了三分之一 — 這個膨脹是固定的，無法避免。

當明確需要文字表示法時，這種取捨是值得的：透過 CSS background-image 渲染的小型內嵌圖示、HTML 電子郵件範本中的單張圖片預覽、JSON 測試資料中的固定字串、影像辨識 API 的承載欄位，或必須以單一文字檔傳遞的離線原型。對於正式網站的傳遞、圖片密集的頁面，或任何一般圖片 URL 或附件就能運作的工作流程來說，它都是糟糕的選擇 — 每個請求都會多出三分之一的位元組、無法像獨立的圖片檔那樣有效率地快取，且每次字串渲染時瀏覽器都會進行解碼。

反向工作流程與相關工具

若要將 Base64 字串轉回可下載的圖片，請使用 Base64 轉圖片轉換器，它共用相同的結構偵測器與瀏覽器解碼驗證。如果您在編碼前需要較小的承載量，請使用 Image Compressor 最佳化原始檔案。如果您先需要新的尺寸，請使用 Image Resizer。若是一般文字而非圖片容器，請改用標準的 Base64 編碼與解碼工作流程。將這些步驟分開意味著您產生的 Base64 是您預期嵌入之位元組的忠實表示，中間不會有隱藏的重新壓縮或 canvas 重寫。

如果您正在權衡各種選項，Base64 轉圖片作為電子郵件附件：取得真正的檔案 詳細介紹了這部分內容。