Base64 編碼與解碼

什麼是 Base64，什麼時候用

Base64 用 64 個可列印 ASCII 字元（A–Z、a–z、0–9、+ 與 /，= 作填充）來表示任意二進位資料。每 3 個位元組的輸入變成 4 個字元的輸出，所以編碼後的資料比原始資料大約大 33%。它存在的原因是很多通道只為文字設計：郵件附件（MIME）、JSON 與 XML 負載、HTTP Basic 認證標頭、JWT 權杖，以及把圖片直接嵌進 HTML 或 CSS 的 data URL。Base64 是編碼而不是加密——任何人都能解碼，絕不要用它來隱藏機密。

URL-safe 變體（RFC 4648 §5）把 + 換成 -、/ 換成 _，通常還去掉 = 填充，這樣結果可以直接放進 URL、檔名與 Cookie 而無需跳脫。JWT 用的就是這種形式。本頁的解碼器兩種變體都接受，並容忍缺失的填充，所以可以直接貼上 JWT 的某一段。

使用方法

輸入或貼上文字，編碼隨輸入自動完成。文字依 UTF-8 處理，所以中文、emoji 及任何 Unicode 字元都能正確往返——直接用 btoa() 的簡陋實作常在這裡出錯。勾選 URL-safe 得到 -/_ 字母表且無填充。按「檔案…」選擇任意檔案：圖片、PDF、字型或壓縮檔都在本機讀取並編碼；對於圖片，輸出是完整的 data URL，可以直接貼到 <img src> 或 CSS 背景裡。

解碼時切換到「解碼」並貼上 Base64（完整的 data URL 也可以）。如果結果是合法的 UTF-8 文字，會顯示在輸出框；如果是二進位，工具會辨識常見格式（PNG、JPEG、GIF、WebP、PDF、ZIP），圖片直接預覽，並可下載解碼後的檔案。「交換」把輸出放回輸入，一鍵驗證往返是否正確。

隱私與限制

檔案不會離開你的電腦。它們透過瀏覽器的 File API 讀取、在記憶體中編碼並顯示給你，不上傳任何內容。因為全部在用戶端執行，實際限制就是裝置記憶體：幾十 MB 的檔案沒有問題，只是輸出框捲動會變慢。超大檔案建議直接下載結果而不是複製。

背景：一個只有文字的世界

Base64 誕生於早期電子郵件的限制。SMTP 是為 7 位元 ASCII 文字設計的，附上一個二進位檔案意味著先把它翻譯成可列印字元；1980 年代的 uuencode 就是做這件事的，而 MIME 標準（RFC 2045，1996）定義了沿用至今的 Base64 字母表。後來 RFC 4648（2006）把各變體收攏到一起：標準 Base64、URL 與檔名安全變體，以及 Base32/Base16。3 位元組變 4 字元的比率，就是編碼後資料恰好是原始大小的 4/3 再加填充的原因——這個代價在撥接上網時代很要緊，在把圖片內嵌進 CSS 時依然要緊。

應用領域

郵件附件的底層仍然是 Base64。data URL 把小圖片和字型直接嵌進 HTML 與 CSS，省掉一次請求——嵌入前先壓縮圖片，因為 Base64 會在原大小上再增加 33%。HTTP Basic 認證把 username:password 用 Base64 傳送（不是加密——務必走 HTTPS）。JWT 權杖是三段用點連接的 URL-safe Base64，標頭和負載解碼出來是 JSON。Kubernetes Secret、雲端平台 IAM 政策、攜帶 Base64 值的百分號編碼 URL、Subresource Integrity 屬性裡的 SHA-256 摘要、SAML 斷言、PEM 憑證（BEGIN 與 END 行之間的區塊）以及 JSON API 裡的二進位欄位全都用它，因為這些系統只能承載文字。當你遇到一個以 = 結尾、或只含字母數字和 + / 的長字串，它幾乎肯定是 Base64，貼到這裡是弄清它內容最快的方式。

常見問題