iLoveDevTool先分流：你手裡的是什麼
「Base64」搜尋框背後是四種不同的活，先看手裡東西的形態：
| 形態 | 你要做的事 | 怎麼做 |
|---|---|---|
一串字母數字，結尾 0-2 個 = |
解出文字內容 | 貼進 Base64 編碼解碼器 解碼，UTF-8 內容直接還原中文 |
data:image/png;base64,... 開頭 |
看這是什麼圖 / 還原成圖片 | 貼進工具——識別 data URI 與圖片簽名（PNG/JPEG/GIF/WebP/BMP），給出預覽 |
| 本機檔案 | 轉成 Base64 內嵌（CSS 小圖示、JSON 傳參） | 切檔案模式上傳（上限 5MB），得到 dataURL 或純編碼 |
| 編碼結果要放進 URL、檔名 | 避免特殊字元出事 | 選 URL-safe 變體（+→-、/→_、去掉 =） |
四種情況共用一個事實：Base64 是可逆編碼，不需要金鑰，貼進工具就能雙向轉換。下面講最容易翻車的三個問題。
亂碼的三大來源
解碼出亂碼，先別懷疑內容壞了，按機率排查：
一、字元集誤讀（最常見）：內容是 UTF-8 編碼的中文，解碼工具卻按 Latin-1 逐位元組顯示——每個漢字的三個 UTF-8 位元組變成三個西歐字元，滿螢幕 ä½ å¥½ 就是這個 pattern。解法：用支援 UTF-8 的工具（本站解碼走 UTF-8 管線，中文直接還原）。
二、本來就是二進位：圖片、壓縮檔、protobuf 序列化資料——它們不是文字，強行按文字渲染當然是亂碼。判斷方法看簽名：解出來開頭是 \x89PNG 是 PNG 圖片、FF D8 FF 是 JPEG、PK 開頭多半是 ZIP——這時候正確動作是還原成檔案而不是當文字讀。帶圖片識別的解碼器會直接給出預覽。
三、多層編碼沒剝乾淨：上游先做了百分號編碼（%E4%BD%A0）再做 Base64，或 JSON 裡的字串轉義沒去掉——逐層剝：先去轉義、再解外層、再解內層。判斷線索是解出來的「亂碼」本身看起來像另一種編碼的形態。
URL-safe：三個字元引發的事故
標準 Base64 的字母表（A-Z a-z 0-9 + /）在純文字世界裡沒問題，但 +、/、= 三個字元各有雷區：
+在 URL 查詢參數裡會被伺服器解析成空格——簽名校驗就是這麼失敗的；/在檔名裡不合法，在 URL 路徑裡會被當成分隔符；=是 padding，放在查詢參數裡部分閘道會截斷或重複解碼。
URL-safe 變體把 +→-、/→_、去掉 =，產出可安全放進 URL、檔名、正則上下文。JWT 的載荷部分用的就是它。判斷標準：這段編碼接下來要去哪裡？ 去 URL/檔名選 URL-safe；只在程式內部傳遞用標準形態，別為「看起來更安全」亂換——兩種形態只是字母表不同，解碼端必須配套。
檔案與 dataURL
把檔案轉成 Base64 的主要產出是 dataURL——data:image/png;base64, 前綴加編碼串，瀏覽器能直接把它當圖片位址用。
划算的用法：幾 KB 的 CSS 內嵌小圖示（省一次請求）、郵件內嵌圖片、設定檔裡攜帶小型二進位資源、給介面傳「小檔案+中繼資料」的複合結構。
不划算的用法：大圖內嵌——體積膨脹三分之一（演算法固有：4 字元表 3 位元組），100KB 圖片編碼後約 133KB，頁面裡塞幾張就把傳輸與解析開銷吃回來了。經驗值：幾 KB 到幾十 KB 的靜態資源適合內嵌，更大走獨立檔案與 CDN。
真話段：Base64 不是加密。無金鑰、演算法公開、一步還原——把密碼或 token 轉成 Base64 當「混淆」，在任何掃描器面前等於明文。它的正當用途是讓二進位資料安全通過文字通道（HTTP 標頭、JSON、URL、郵件），與保密無關。要保密用加密，要管密碼用密碼管理器。
常見問題
Base64 解碼出來是亂碼怎麼回事？
三個來源按機率排：一是字元集誤讀——內容是 UTF-8 編碼的中文，但檢視工具按 Latin-1 逐位元組顯示，解出來必然是亂碼，換支援 UTF-8 的解碼工具即好；二是解的本來就是二進位，強行按文字渲染當然是亂碼——看開頭幾個位元組的簽名判斷真實型別；三是編碼源頭就錯了，比如上游先做了百分號編碼再 Base64，需要逐層剝。先判斷手裡的是什麼，再選解法。
Base64 是加密嗎？用它藏密碼安全嗎？
不是，完全不安全。Base64 是編碼不是加密：演算法公開、無金鑰、任何人都能一步還原。把密碼轉成 Base64 的唯一效果是「肉眼不可讀」，對攻擊者等於沒設防——它出現在無數掃描器的預設字典裡。真正的保密要靠加密或更好的方案——密碼管理器與憑證儲存。Base64 的正當用途是「讓二進位安全地過文字通道」，與保密無關。
什麼時候必須用 URL-safe Base64？
標準 Base64 的字母表裡有 + / = 三個字元，它們在 URL 裡有歧義（+ 會被解析成空格）、在檔名裡不合法、在正則裡要轉義。URL-safe 變體把 + 換成 -、/ 換成 _、去掉 padding 的 =，產出可以安全放進 URL 路徑、查詢參數、檔名。判斷標準：這段 Base64 接下來要去哪裡？去 URL/檔名就用 URL-safe；只在程式內部傳遞就用標準形態。
為什麼圖片轉成 Base64 後體積變大了？
Base64 用 4 個字元表示 3 個位元組，任何內容編碼後體積固定膨脹約 33%——100KB 的圖片編碼後約 133KB。這是演算法代價不是 bug。用它做 CSS 內嵌小圖示、郵件內嵌資源是划算的（省一次請求）；把大圖轉 Base64 塞進 JSON 或 CSS，頁面體積與解析開銷都會明顯上漲。經驗值：幾 KB 到幾十 KB 的靜態小圖適合內嵌，再大就該走獨立檔案與 CDN。