Base64 幾乎無所不在：前端把圖片轉成 Data URL、後端在 API 內傳遞二進位資料、JWT 使用 Base64URL 表示 Header 與 Payload、Email 附件也常透過 Base64 封裝。很多人會用，但也常誤解。最常見的誤解是把 Base64 當作「加密」。其實 Base64 只是編碼，不是保護資料的安全機制。
一、Base64 是什麼？一句話先說清楚
Base64 是一種把二進位資料轉換為 ASCII 可列印字元的編碼方式。它的目的不是隱藏內容，而是讓資料能在只支援文字的通道中安全傳遞，例如舊式郵件系統、部分 HTTP 欄位或 JSON 字串欄位。
Base64 字元集包含 64 個符號：A-Z、a-z、0-9、+、/，必要時會用 = 做補位。
二、編碼原理：為什麼會膨脹大約 33%
Base64 的核心邏輯是把每 3 個位元組（24 bits）拆成 4 組，每組 6 bits。每組 6 bits 可表示 0 到 63，剛好對應 64 個字元表。
- 原始資料每 3 bytes 會變成 4 個字元。
- 因此大小比約為 4:3，資料量平均增加約 33%。
- 若原始長度不是 3 的倍數，末尾會加上
=補位。
這也是為什麼把大檔案直接轉成 Base64 後放進 JSON 會讓封包體積明顯變大，進而影響傳輸與解析效能。
三、Base64 與加密、雜湊有何不同？
| 技術 | 目的 | 可逆性 | 常見用途 |
|---|---|---|---|
| Base64 | 資料轉為文字格式 | 可逆 | 傳輸二進位內容、Data URL、JWT 結構片段 |
| Encryption | 保護機密性 | 有金鑰才可逆 | 敏感資料保護（AES、RSA） |
| Hash | 產生摘要 | 不可逆 | 完整性驗證、密碼儲存（搭配 salt） |
如果你把密碼「先 Base64 一下」就存進資料庫，等於幾乎沒有保護。任何人都能秒解碼。密碼應使用強雜湊演算法（如 Argon2、bcrypt）並搭配 salt。
四、實務場景：什麼時候適合用 Base64？
1. API 傳輸少量二進位資料
例如簽章、短憑證片段、少量圖片縮圖可用 Base64 放進 JSON。若是大型檔案，建議改走檔案上傳通道（multipart/form-data 或物件儲存 URL）。
2. Data URL 內嵌資源
在 HTML/CSS 內可使用 data:image/png;base64,... 內嵌小圖示，減少請求數。但若圖片偏大，反而使文件膨脹並降低快取效率。
3. JWT 的 Base64URL
JWT 使用的是 Base64URL 變體，將 +、/ 替換為 -、_，並通常省略補位符號 =，以利放入 URL 與 Header。
五、Base64URL 是什麼？
Base64URL 是為了 URL 安全而設計的變體，不是新演算法。轉換規則如下：
+改為-/改為_- 尾端
=可省略
當你在 OAuth、JWT、URL token 場景看到字串不含 + 與 / 時，多半就是 Base64URL。
六、常見錯誤與排查方式
- 錯誤的字元集：把 Base64URL 當標準 Base64 解碼會失敗。
- 補位遺失：部分程式庫要求正確補位，否則報錯。
- 重複編碼：資料被 encode 兩次，解碼一次後仍看起來像亂碼。
- 字串編碼混亂：UTF-8/UTF-16 轉換不一致造成內容失真。
排查建議：先確認資料來源格式（Base64 或 Base64URL），再檢查補位與字元集，最後用小樣本做 encode/decode 回圈驗證。
七、效能與安全建議
- 避免把大型二進位檔直接塞進 JSON 的 Base64 欄位。
- 前後端溝通時先約定使用標準 Base64 或 Base64URL。
- 不要把 Base64 當成保護機制，敏感資料仍需加密與權限控管。
- 記錄與監控解碼錯誤率，能提早發現資料管線問題。
結語
Base64 的價值在於相容性，而不是安全性。只要掌握它的資料膨脹特性、URL 變體差異與實務使用邊界，就能在 API 與前端整合中做出更穩定的技術決策。