若要在 JavaScript 中將影像轉換為 Base64 字串，標準作法是對 File 或 Blob 呼叫 FileReader.readAsDataURL，它會回傳一個格式為 data:image/<type>;base64,<payload> 的 data URL，其中影像的每三個位元組會變成四個 RFC 4648 字元。即使不撰寫任何程式碼，也能輕鬆達到相同的目標——也就是一個可貼到 JSON 承載、HTML img src 屬性或 CSS 背景中的純 Base64 字串——只要把檔案交給一個會為你執行編碼步驟的專用瀏覽器工具即可。這兩條路徑並存的原因在於，Base64 本身並非 JavaScript 的發明；它是 RFC 4648 規範中定義的一種傳輸字母表，任何語言——包含在你瀏覽器分頁中執行的 JavaScript——都能產生它。不同方法之間的差別在於，你必須自己串接多少驗證、MIME 偵測與剪貼簿處理。
你原本會撰寫的 JavaScript 方法
大多數「JavaScript 影像轉 Base64」的教學與 Stack Overflow 回答都涵蓋三種模式，而每一種都帶有一個會由專用工具為你處理的尖銳問題。
第一種模式使用包裝在 load 處理函式中的 FileReader.readAsDataURL(file)。它適用於任何 File 或 Blob，回傳包含 MIME 前綴的完整 data URL，且不需要伺服器往返。尖銳問題在於，回傳前綴中的 MIME 是直接取自作業系統或你的 accept 過濾器所傳入的值——若檔案其實是被重新命名為 photo.jpg 的 PNG，輸出仍會標示為 data:image/jpeg;base64,…
第二種模式將影像繪製到 canvas 元素，然後呼叫 canvas.toDataURL('image/png')。這讓你能同時調整大小、重新壓縮或更改格式，但它也會重寫位元組：EXIF 會被捨棄，調色盤項目會被量化，動畫 GIF 與 WebP 會失去動畫。若你需要原始位元組——而非重新編碼——canvas 就是錯誤的工具。
第三種模式使用 fetch(url).then(r => r.blob()).then(b => new FileReader().readAsDataURL(b))。這是處理跨來源影像的正確形狀，但僅在伺服器傳送寬鬆的 CORS 標頭時成立，否則它會靜默失敗。這三種做法都不會驗證位元組是否真的是 PNG、JPEG、GIF 或 WebP 容器：它們只信任宣告的 MIME、檔案副檔名或伺服器回應。
透過瀏覽器型轉換器跳過程式碼
當你不需要把轉換嵌入到更大的 JavaScript 管線中時，Image to Base64 Converter 會以三項優勢產生相同的字串：它檢查實際位元組以判斷容器，它要求瀏覽器本身在發布結果前先解碼影像，且它絕不會把檔案傳送到任何地方。檔案讀取、容器偵測、瀏覽器解碼、Base64 編碼與剪貼簿寫入，全部都在目前分頁中完成。當結果變更或工具關閉時，暫時性的 ObjectURL 會被撤銷。
這使得該工具非常適合用於 API 承載、JSON fixture、HTML 或 CSS 實驗、電子郵件範本、離線原型、測試資料，以及必須將既有影像以文字表示的除錯工作流程。它並非一般網站上一般影像託管的替代品，也不應被視為如此——請參閱下方關於大小的說明。
逐步將影像轉換為 Base64
- 在你的瀏覽器分頁中開啟 Image to Base64 Converter。
- 從檔案選擇器挑選一個本機的 PNG、JPEG、GIF 或 WebP 檔案。
- 選擇你要的是僅含 Base64 字元的純文字，還是完整的 data:image/<type>;base64,… data URL。
- 執行轉換，並確認偵測到的位元組格式、實際解碼後的尺寸、檔案大小與螢幕上的預覽都符合預期。
- 使用複製按鈕複製完整輸出。在 data URL 模式下，前綴中的 MIME 是取自已驗證的位元組——被重新命名為 photo.jpg 的 PNG 仍會產生 data:image/png;base64,…
若檔案過大、容器位元組被截斷、無法在瀏覽器中解碼，或超出尺寸限制，工具會顯示明確的錯誤並清除任何先前的成功結果，避免你不慎複製到過時的字串。
純 Base64 與 Data URL 輸出的差異
你可以要求轉換器以兩種形狀輸出，端看文字會被貼到哪裡。
| 模式 | 你複製的內容 | 適用情境 |
|---|---|---|
| 純 Base64 | 僅含規範的 RFC 4648 字母：A–Z、a–z、0–9、+、/，當最後一組少於三個輸入位元組時再加上一或兩個結尾的 = 號。 | JSON 請求主體、API 承載、設定欄位、手動解碼管線。 |
| Data URL | 以 data:image/<type>;base64, 開頭的完整字串，後接相同的承載內容，其中 <type> 取自已驗證的容器位元組。 | HTML img src 屬性、CSS background-image 值、遠端影像被封鎖時的電子郵件範本。 |
編碼完全遵循 RFC 4648 字母表。三個輸入位元組會被分組並寫成四個字元，因此 N 位元組的檔案會產生 ceil(N / 3) × 4 個字元，包含任何尾端的 = 填補。編碼器會處理三個位元組對齊的有界區塊，而不是把整個緩衝區攤開成單一變動參數呼叫，因此數 MB 的影像不會溢位 JavaScript 呼叫堆疊。串接區塊只會改變結果的組裝方式，編碼後的位元組絕不會被縮短或換行。
輸入限制與邊界時的行為
轉換器套用了一組嚴格的限制，以保證能給出真正完成的輸出，而非半成品。每個限制都會被精確檢查：邊界值會被接受，超過一個單位則會被拒絕。
| 限制 | 接受的值 | 拒絕的值 |
|---|---|---|
| 輸入檔案大小 | 5 MiB = 5,242,880 位元組 | 5,242,881 位元組 |
| 解碼後邊長 | 較長邊 20,000 px | 任一邊 20,001 px |
| 解碼後總像素 | 40,000,000 像素 | 40,000,001 像素 |
| 純 Base64 長度 | 6,990,508 字元 | 6,990,509 字元 |
| 最長 data URL | 6,990,531 字元 (data:image/webp;base64, = 23 字元 + 6,990,508 承載字元) | 6,990,532 字元 |
你可以直接驗證 Base64 上限。5,242,880 個輸入位元組分成三個位元組一組，可得到 1,747,626 個完整群組，再加上 2 個剩餘位元組，編碼器會將其寫成 1,747,627 組、每組 4 個字元：1,747,627 × 4 = 6,990,508 個純 Base64 字元。加上 23 字元的 WebP 前綴 data:image/webp;base64,，最長的 data URL 輸出為 6,990,531 字元。過大的檔案會在讀取主體之前產生明確錯誤，並在讀取後再次檢查實際的 ArrayBuffer 長度。任何值都不會被悄悄截斷。
像素面積與邊長限制之所以重要，是因為壓縮後的位元組在瀏覽器將其解碼為點陣圖時會大幅膨脹。一個小檔案若代表極高或極寬的畫布，仍可能因尺寸檢查而失敗；一個大檔案若代表一張合理的影像，仍可能因面積檢查而失敗。能否成功解碼取決於壓縮，而非檔案選擇器。
Base64 何時真正有用，何時有害
Base64 編碼是傳輸技巧，不是壓縮技巧。每三個輸入位元組會變成四個文字字元，因此在加上任何 data URL 前綴之前，編碼後的文字大約比原始檔案大三分之一。當你明確需要文字表示時，這個成長是可接受的——例如把影像嵌入不接受二進位的 API JSON 承載、把一個小圖示內嵌進 CSS 檔以供離線使用，或把一張小照片複製到會移除遠端參考的電子郵件範本中。但在一般網頁傳遞上，它是不好的選擇，因為一般影像檔與 CDN URL 壓縮效率更佳、快取效果更強，且能與 HTML 平行串流。
轉換器也會在 Base64 承載中保留原始影像位元組。它不會繪製到 canvas、調整大小、重新壓縮、改變顏色、壓平透明度、選擇 GIF 影格、移除詮資料、修復損壞或最佳化檔案大小。當下游消費者支援動畫時，動畫 GIF 與 WebP 的位元組會保持動畫。若你想要更小的承載，請先用 Image Compressor 最佳化檔案。若你想要不同的尺寸，請先用 Image Resizer。把這些步驟分開處理，可以避免隱性重新壓縮，並讓編碼後的輸出可預期。
編碼前後的相關工作流程
在 Base64 轉換的前後，常會出現三個相鄰的工作。
- 編碼前先縮小檔案。若你的目標是更短的 data URL，請先把影像送入 Image Compressor。編碼長度會直接隨來源位元組縮放，因此檔案減半大致會讓 Base64 字串減半。
- 編碼前先調整大小。若來源畫布尺寸不符，請在編碼前使用 Image Resizer 設定精確的像素尺寸。Base64 承載將精確代表這些像素。
- 反向解碼。若你收到一串 Base64 並需要取回原始影像，反向工作流程是 Base64 to Image Converter，它會驗證容器並顯示預覽。
若處理的是一般文字而非影像容器，請使用 Base64 Encode and Decode。若要產生靜態影像 ASCII 藝術，請參閱 Image to ASCII 或 Text to ASCII Art Generator。若你需要完全不同的影像格式——SVG、AVIF、HEIC、BMP、TIFF、PDF——轉換器依設計不在其適用範圍內；請先使用專用的格式轉換器，以確保位元組真的符合消費端預期。
若你正在權衡選項，Base64 影像過大：在你的瀏覽器中取得真正的檔案 對此有詳細說明。