Base64 可以解密嗎？
Base64 沒有「加密」，自然也談不上「解密」，準確的說法是解碼，而且一定能解開——把上面切到解碼模式，貼進去點一下就是原文。它和 MD5、SHA-256 那種單向雜湊完全不同：後者不可逆，Base64 是完全可逆的雙向編碼。如果你看到有人用 Base64 來「加密」敏感資料，那是個安全問題，不是加密方案。
data:image/png;base64,... 這類整段 data URI，會自動辨識並剝掉前綴。解出來是圖片會直接預覽，是二進位會給下載按鈕。全部在瀏覽器本機完成，不上傳任何資料。data: URI，前綴會自動剝掉；換行、空格也會自動忽略。-_）和缺少的 = 補位，不用手工修。不算，而且這是最要緊的一條。Base64 是編碼：把任意二進位資料用 64 個可列印字元（A-Z a-z 0-9 + /）重新表達一遍，沒有金鑰、沒有祕密，規則是公開的，任何人拿到都能一步還原。它解決的是「這條通道只能傳文字，我要塞一張圖片進去」的問題，不是「我要讓別人看不懂」的問題。所以把密碼、身分證字號、API 金鑰 Base64 一下再存進資料庫或寫進前端程式碼，等於沒做任何保護——真正要不可逆請看 SHA-256 線上加密，要存密碼請用 bcrypt 這類慢雜湊。
這類連結長得像 data:text/html;charset=utf-8;base64,PGh0bWw+...，常見於 QQ 郵箱、部分論壇的「分享」功能。打不開不是連結壞了：Chrome 從 2017 年起禁止在網址列直接開啟頂層 data: 連結，Firefox、Edge 隨後跟進，因為這個特性被大量用於釣魚——偽造的登入頁可以整個塞進一條連結裡，且網址列顯示不出真實網域。
內容本身還在連結裡。把整段連結（連 data:text/html;charset=utf-8;base64, 這段前綴一起）貼進上面的解碼框，本頁會自動辨識前綴、剝掉、再解出原文。如果解出來是 HTML，你會看到完整的網頁原始碼。看之前先有個心理準備：如果這條連結是陌生人發來的，它有相當機率是釣魚頁，解出來看看內容可以，別照著裡面的表單填帳號密碼。
主要是內嵌：把小圖示直接寫進 CSS 的 background-image: url(data:image/png;base64,...) 或 HTML 的 <img src>，省掉一次 HTTP 請求；也用於把圖片塞進 JSON、Markdown 或郵件內文這類只能放文字的地方。代價是體積會漲約 1/3（每 3 位元組變 4 字元），而且內嵌的圖片沒法被瀏覽器單獨快取——改一個位元組整個 CSS 檔案的快取就失效了。所以只適合幾 KB 的小圖示，照片和大圖老老實實走 URL。上面勾選「加上 data URI 前綴」就能直接得到可以貼進程式碼的完整字串。
那是 URL 安全變體（RFC 4648 §5）。標準字母表裡的 + 和 / 在 URL 和檔案名稱裡有特殊含義，放進查詢參數會被跳脫或截斷，所以換成 - 和 _；結尾用來補齊長度的 = 在 URL 裡同樣礙事，常被直接省略。JWT 的三段就是這麼編的。本頁解碼時會自動認出這兩種寫法並還原，不用你手工替換；編碼時勾上「URL 安全字元集」就能輸出這種形式。
Base64 沒有「加密」，自然也談不上「解密」，準確的說法是解碼，而且一定能解開——把上面切到解碼模式，貼進去點一下就是原文。它和 MD5、SHA-256 那種單向雜湊完全不同：後者不可逆，Base64 是完全可逆的雙向編碼。如果你看到有人用 Base64 來「加密」敏感資料，那是個安全問題，不是加密方案。
先看提示。本頁解碼後會嘗試按 UTF-8 讀，讀不通就說明它本來就不是文字——是圖片、PDF 或壓縮檔，這時會告訴你嗅探到的格式並給出下載按鈕，直接下載才是正確操作，硬看當然是亂碼。如果確定應該是文字卻仍然亂，多半是原文用了 GBK 等非 UTF-8 編碼，本頁統一按 UTF-8 解，這種情況需要用支援指定字元集的工具。
三種常見情況：一是複製時漏掉了結尾幾個字元，導致長度不是 4 的倍數且補不齊；二是內容裡混進了 Base64 字母表以外的字元，比如從聊天記錄裡複製時帶上了中文引號或刪節號；三是這段字串其實是 URL 編碼（%3Chtml%3E 那種）而不是 Base64。換行和空格不會導致這個錯誤，本頁會自動忽略。
Base64 用 4 個字元表示 3 個位元組，所以固定膨脹到原來的 4/3，約多 33%，再加上末尾的補位字元。這是原理決定的，任何 Base64 工具都一樣，不是本頁的問題。如果體積敏感，正確的做法是先壓縮再編碼，或者乾脆不內嵌、改用 URL 引用。
編碼模式限制 10 MB。這個上限不是技術極限，而是因為再大就沒有意義了：Base64 的用途是內嵌到文字裡，一個 10 MB 的檔案編完是 13 MB 的字串，貼到哪裡都會出問題。解碼模式沒有硬性上限，但瀏覽器處理超長字串會變慢，幾十 MB 的輸入可能會卡一下。
不是。URL 編碼（百分號編碼）只把 URL 裡的特殊字元換成 %XX，其餘字元原樣保留，結果人還能讀個大概；Base64 會把全部內容重新表達成 64 個字元，結果完全不可讀，但能安全承載任意二進位。兩者經常一起出現：把 Base64 結果放進 URL 參數時，如果用的是標準字母表，裡面的 + 和 / 還需要再做一次 URL 編碼——這也正是 URL 安全變體存在的原因。
可以，但要注意字元集。Base64 處理的是位元組不是字元，所以必須先把中文按某種編碼轉成位元組。本頁統一用 UTF-8，這也是目前的通行做法。同一段中文按 GBK 編碼再 Base64，結果和 UTF-8 完全不同，兩邊對不上時先確認字元集，而不是懷疑 Base64 實作有問題。
不會。轉換用的是瀏覽器內建的 atob / btoa 和 FileReader，檔案讀進記憶體、轉換完直接顯示，沒有一個位元組離開你的裝置。頁面載入完之後斷開網路，這個工具照常可用——這是最直接的驗證方法。詳見隱私權政策。