Base64 解碼是將 Base64 編碼字串——由 A–Z、a–z、0–9、"+"，"/" 以及 "=" 等字元組成的序列——轉換回原始文字或二進位形式的過程。標準字母表定義於 RFC 4648，正好使用 64 個可列印字元加上填補字元。每四個 Base64 字元對應三個原始位元組，因此長度為 12 個字元的 Base64 字串會解碼為 9 個原始位元組。由於編碼形式僅使用 ASCII 安全的字元，因此它能夠通過那些會破壞原始二進位資料的系統（例如電子郵件、JSON、URL、設定檔）來傳輸。
每當人們看到一串看似亂碼但顯然並非隨機的字母時，就會搜尋 Base64 解碼器——典型的特徵包括結尾的等號、"+" 與 "/" 符號，以及長度永遠都是 4 的倍數。你可能正在除錯 JWT 權杖、檢查 API 回應、讀取樣式表中的 data URI，或是嘗試讀取為了安全而經過編碼的設定值。從「這是什麼字串？」到「啊，這就是純文字」的最快路徑，就是一個能立即解碼並讓你複製結果的工具。
Base64 編碼長什麼樣子
Base64 會取三個位元組（24 位元）的輸入，將其分割為四個 6 位元的群組，然後將每個群組對應到 64 字元字母表中的一個字元。輸出結果大約比原始資料長 33%——3 個位元組會變成 4 個字元。當輸入長度不是 3 的倍數時，編碼器會以 "=" 字元填補輸出，使編碼字串的長度永遠是 4 的倍數。
舉例來說，三個字母 "Cat"（每個字母佔一個位元組：67、97、116）會變成 Base64 字串 "Q2F0"。再加上許多文字檔案結尾的換行字元後，就變成 "Q2F0Cg=="。當你解碼 "Q2F0Cg==" 時，就會取回 "Cat" 後面接著一個換行字元。結尾的兩個 "=" 符號告訴解碼器，最後一個群組只包含一個實際的位元組。
為什麼人們需要 Base64 解碼
Base64 出現在許多必須將二進位資料搭載在純文字傳輸之上的場合。網頁開發者會在 data URI（data:image/png;base64,iVBOR...）以及 Authorization: Basic 標頭中遇到它。API 使用者會在 JSON Web Token 中看到它，其中 header 與 payload 都是經過 Base64 編碼（但並未加密）。電子郵件系統使用它，透過原本設計用於純文字的協定來傳送附件。設定檔有時會將密鑰或憑證儲存為 Base64 區塊，以免換行符號與引號造成損壞。
在上述所有情況中，編碼值在解碼回可讀的內容之前都是無用的。像 eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIERvZSJ9 這樣的 JWT payload，一旦通過 Base64 解碼器處理，就會立刻變成 JSON 物件 {"sub":"12345","name":"John Doe"}。這個轉換作業正好就是免費線上工具的設計目的。
如何在瀏覽器中解碼 Base64 文字
Base64 編碼 / 解碼工具在本機端執行轉換，因此你的輸入內容永遠不會離開這個頁面。它支援雙向轉換，讓你可以在編碼與解碼之間切換而無需重新載入。
- 開啟工具並選擇方向。如果你擁有 Base64 字串並想取回原始文字，請選擇 解碼 (Decode)；如果你擁有純文字並想要 Base64 形式，請選擇 編碼 (Encode)。
- 將輸入內容貼到上方的輸入框。輸出會在你輸入或貼上時即時更新，因此你可以貼上一長串字串並立即觀看它被解析。
- 在下方的輸出框中讀取結果。如果輸入內容不是有效的 Base64，工具會標示錯誤，而不是靜默地回傳亂碼。
- 點擊 複製 (Copy) 來取得解碼後的文字，或點擊 交換 (Swap) 將結果再次送回編碼器，確認整個來回轉換是無損的。
由於轉換是即時的，且輸出就在同一個頁面中，你可以持續微調輸入，直到解碼後的文字合理為止。這裡沒有需要尋找的提交按鈕，也沒有需要等待的上傳進度條。
了解常見的解碼陷阱
有些事情會在第一次解碼 Base64 時造成困擾，認出這些狀況可以省下大量時間。
填補字元。有效的 Base64 字串結尾會有零個、一個或兩個 "=" 字元。如果這些字元被去除（有些系統為了節省空間會修剪填補字元），大多數解碼器仍然能處理輸入，但嚴格的驗證器可能會拒絕它。Base64 解碼工具可以容忍缺少的填補字元。
URL 安全變體。標準字母表使用 "+" 與 "/"。URL 安全變體會將它們替換為 "-" 與 "_"，使字串可以放在查詢參數中而無需進行百分比編碼。如果你的字串在你預期為加號或斜線的位置出現了連字號或底線，請切換到 URL 安全字母表。
多行輸入。Base64 原本會以每行 76 個字元進行換行（依據 MIME 規範），並以 CRLF 作為分隔符號。將換行後的版本貼到工具中，它會自動為你去除換行符號。
UTF-8 來回轉換。表情符號、附有變音符號的字母以及非拉丁文指令碼在 UTF-8 中會以多位元組序列儲存。正確的解碼器會將輸入視為位元組流並重新組合這些序列，這正是線上工具的作法。假設為 Latin-1 的解碼器則會破壞前 256 個碼位以外的任何內容。
編碼 vs. 解碼：何時該使用哪個方向
編碼會將可讀的文字轉換為安全的 ASCII 字母表，當你需要將特殊字元嵌入僅支援純文字的環境時非常有用——例如，將小圖片以 data URI 的形式嵌入 CSS 檔案中。解碼則執行相反的動作，當你處於這類嵌入的接收端時就會需要它。
| 方向 | 輸入 | 輸出 | 典型使用情境 |
|---|---|---|---|
| 編碼 (Encode) | 純文字或二進位 | Base64 字串 | 將圖片嵌入 CSS data URI、透過 JSON 傳送二進位資料 |
| 解碼 (Decode) | Base64 字串 | 純文字或二進位 | 讀取 JWT payload、檢查 data URI、復原設定值 |
同一個工具就能處理這兩個方向，因此你不需要第二個頁面。當你想要驗證來回轉換是否無損時，交換 (Swap) 按鈕特別好用：先解碼字串，再將結果編碼，然後確認你取回了原本的 Base64。
Base64 與其他常見的編碼方式
Base64 是你在日常工作中會遇到的數種純文字安全編碼之一。了解你正在查看的是哪一種，可以避免將錯誤的輸入送進錯誤的工具。
| 編碼方式 | 字元集 | 用途 |
|---|---|---|
| Base64 | A–Z、a–z、0–9、+、/、= | 將二進位資料表示為 ASCII 文字 |
| URL 百分比編碼 | % 後接兩個十六進位數字 | 跳脫 URL 與查詢字串中的字元 |
| 二進位文字 | 0 與 1 | 將原始位元顯示為一串數字 |
| 摩斯密碼 | 點、劃與分隔符號 | 透過無線電傳送文字 |
如果你盯著一串充滿 "%20" 與 "%3D" 的字串，那是 URL 編碼，URL 解碼器才是合適的工具。每個字母剛好由 8 個字元組成的 1 與 0 字串是二進位文字，二進位轉文字轉換器可以讀取它。點與劃組成的序列是摩斯密碼，由摩斯密碼翻譯器處理。若想更深入了解 Base64 在更廣泛編碼領域中的定位，逐步指南如何立即解碼 Base64 文字會以額外的範例帶你走過相同的工作流程。
Base64 的安全性注意事項
Base64 是編碼，不是加密。解碼 Base64 字串不需要金鑰，這表示任何能看到編碼資料的人都能讀取它。請將任何僅經過 Base64 編碼的密鑰視同以純文字儲存。如果你需要保密性，請在其上加上一層真正的加密——或者使用密碼產生器來建立一組強健的金鑰，並以妥善的加密來保護資料，而不是依賴編碼所帶來的隱晦性。
基於相同的原因，切勿盲目信任解碼後的內容。惡意製作的 Base64 字串可能解碼為可執行的位元組、HTML 或腳本。如果你解碼的內容來自不受信任的來源，請先掃描或沙箱化該結果再執行。
快速參考：Base64 字母表與填補字元
完整的字母表（依 RFC 4648 所定義）將 A–Z 對應到 0–25、a–z 對應到 26–51、0–9 對應到 52–61、"+" 對應到 62、"/" 對應到 63。填補作業使用 "="，它不屬於資料字母表的一部分，但表示最後一個群組少於 24 位元。了解字母表有助於你懷疑是否有打錯字——如果你看到該集合之外的其他字元，該字串就不是標準 Base64，解碼器會去除雜訊或回報錯誤。
不過，對於大多數日常工作來說，你不需要背誦這個表格。只要將字串貼到Base64 解碼工具中，讀取結果，然後繼續進行下一步。這正是在瀏覽器內提供快速解碼器的全部意義。
如果你正在權衡各種選項，如何快速翻譯摩斯密碼（免費線上方法）對此有詳細說明。
如果你正在權衡各種選項，無需撰寫程式就能在瀏覽器中解碼 URL對此有詳細說明。
如果你正在權衡各種選項，無需安裝任何東西，直接從命令列解碼 Base64對此有詳細說明。