Base64 解碼範例是把由 64 字元字母表組成的字串還原成原始位元組的逐步說明。解碼「TWFu」會得到「Man」；解碼「SGVsbG8=」會得到「Hello」；解碼「8J+YgA==」會得到露齒笑表情符號 😀。每個解碼範例都遵守同一條規則：輸入裡每四個字元代表輸出的三個位元組，而「=」填充用來標示最後一組只帶一個或兩個位元組、而不是三個。解碼是編碼的精確逆運算，但最乾淨的示範需要能正確處理 UTF-8 的工具，好讓帶音調字元與表情符號能完成往返，而不是丟出錯誤。
以上是精簡版。本文其餘部分會走六個具體的 Base64 解碼範例——從單字母輸入一路到四位元組表情符號——示範一組經典配對的位元層數學，並說明 Base64 字串在真實程式碼裡實際出現的位置，讓這些範例有落地感、而不是抽象。若你現在只想把字串丟進能用的解碼器，Base64 編碼／解碼工具 是核對下方任何一對最快的方式。
解碼 Base64 字串實際代表什麼
Base64 把任意位元組序列改寫成可列印文字的子集，取自 A–Z、a–z、0–9，再加上符號 + 與 /，而 = 保留給填充。解碼是逆運算：每組四個輸入字元會被拆回三個位元組的二進位資料。RFC 4648 §4 之所以選這套字母表，是因為那 64 個字元能撐過會剝掉或改寫原始位元組的通道——JSON 字串、HTTP 標頭、電子郵件本文、URL 參數、組態檔。
解碼之所以存在，是因為不是每條通道都接受任意二進位。一張直接嵌進 HTML 的圖片會含有看起來像引號或角括號的位元組，進而弄壞剖析器。SMTP 電子郵件本文是為 7 位元 ASCII 設計的。Basic HTTP 驗證標頭走在不允許控制字元或非 ASCII 位元組的標頭欄位裡。Base64 是公認的做法，能把任何位元組序列以每一層都能原樣承載、不必重新解讀的形式，送過那些通道。
解碼 Base64 字串時，結果是位元組，不是字元。那些位元組只有在你也知道該用什麼編碼來解讀時，才會變成可讀文字。把它們當 Windows-1252 會得到亂碼；當 UTF-8 則帶音調字母與表情符號會正確呈現。這就是為什麼紮實的 Base64 解碼範例一律也會標明文字編碼——多數現代工具預設假設 UTF-8，而 Base64 編碼／解碼工具也遵循同一慣例。
六個 Base64 解碼範例，從純 ASCII 到表情符號
把解碼內化最快的方式是看配對。下表使用每個符合 RFC 4648 的解碼器都必須產出的輸出；若你把右欄貼進能用的解碼器，應該會得到恰好等於左欄的結果。
| 原始文字 | Base64 字串 | 位元組 | 填充 |
|---|---|---|---|
| f | Zg== | 1 | == |
| fo | Zm8= | 2 | = |
| foo | Zm9v | 3 | （無） |
| Hello | SGVsbG8= | 5 | = |
| Café | Q2Fmw6k= | 5 | = |
| 😀 | 8J+YgA== | 4 | == |
前三列顯示經典的短輸入行為：當輸入從一個位元組成長到三個位元組，填充會從兩個等號縮到沒有，因為三個位元組能乾淨裝進四個 Base64 字元、沒有剩餘。「Hello」需要一個填充，因為五個位元組在第一組三個之後會留下一個懸空的位元組。「Café」帶進 UTF-8 的曲折：é 編成兩個位元組（0xC3 0xA9），所以這個五字元字串在線上實際是五個位元組——而這正是為什麼只懂 Latin-1 的天真解碼器一試就失敗。最後一列顯示單一表情符號 😀，它在 UTF-8 裡是四個位元組（0xF0 0x9F 0x98 0x80），需要兩個填充。
若你想更深入看字母表本身，Base64 解碼速查表 會逐步說明每個字元的 6 位元值與填充規則。
逐步演練：把「TWFu」從位元解碼到位元組
「Man」是 RFC 4648 的經典範例，所以解碼它能展示機制，而不帶任何 UTF-8 複雜度。Base64 字串是「TWFu」，四個字元。
第一步，在 Base64 字母表裡查每個字元。T 的索引是 19，W 是 22，F 是 5，u 是 46。（大寫 A–Z 對應 0–25，小寫 a–z 對應 26–51，數字與符號字元接在後面；上方連結的速查表有完整對照表。）
第二步，把每個索引寫成 6 位元二進位組。
- T = 19 → 010011
- W = 22 → 010110
- F = 5 → 000101
- u = 46 → 101110
第三步，把四個 6 位元組合接成一條 24 位元串流：010011 010110 000101 101110。那是 24 位元，能乾淨切成三個 8 位元位元組。
第四步，把 24 位元串流切成三個 8 位元位元組。
- byte 1: 01001101 = 0x4D = 77 = 'M'
- byte 2: 01100001 = 0x61 = 97 = 'a'
- byte 3: 01001110 = 0x4E = 78 = 'n'
第五步，沒有填充，所以沒什麼要剝掉。解碼結果是 ASCII 字串「Man」。這正是每個合規解碼器對每一段 Base64 字串執行的過程，只是位元計數藏在程式碼裡。
為什麼有些工具會解碼錯（以及如何做對）
你在網路上找到的幾乎每一個壞掉的 Base64 解碼範例，壞的原因都一樣：它假設解碼後的位元組是 Latin-1 而不是 UTF-8。瀏覽器內建的 btoa() 與 atob() 函式只接受碼點 0 到 255，所以你一餵「café」就會得到 DOMException；一餵中文字或表情符號，同樣的例外會觸發。忽略這個問題的工具常常「解決」它的方式，是默默把壞位元組換成 Unicode 替換字元，產出看起來略微損毀、卻從不丟錯的輸出。
正確的解碼器分兩步做。首先，把 Base64 字串解碼成原始位元組。其次，讓那些位元組走嚴格 UTF-8 解碼器（fatal:true 變體），好讓畸形位元組序列被拒絕，而不是默默弄壞。Base64 編碼／解碼工具用這條精確管線處理兩個方向：編碼時 TextEncoder 產出 UTF-8 位元組，解碼時嚴格 UTF-8 解碼器驗證位元組串流。這就是為什麼 café 往返仍是 café、你好往返仍是 你好、😀 往返仍是 😀，而不是丟例外。
如何在瀏覽器裡解碼 Base64
- 選 Decode 方向，讓工具知道你要的是 Base64 → 文字，而不是文字 → Base64。
- 把 Base64 字串——有填充或無填充——貼進輸入框；解碼後的文字會立刻出現在下方輸出框，不必按任何按鈕。
- 若輸出本身是你想再編碼、或餵進下一步的東西，點選 Swap direction 即可翻轉編碼器，不必重打字串。
- 結果看起來正確時點選 Copy，或把新字串貼進同一個輸入以覆寫輸出。
- 若輸出框顯示的是錯誤而不是文字，表示 Base64 字串要嘛畸形（非法字元、填充長度不對），要嘛底層位元組不是有效 UTF-8；兩種情況都會在任何靜默替換發生之前被攔下。
整條流程用 Web Crypto 世代的 API 在本機執行，因此你貼上的字串——權杖、組態片段、解碼後的 JWT 區段，任何東西——都不會離開你的機器。
解碼 Base64 時的陷阱
少數幾種模式就能解釋大多數解碼失敗與意外。
結尾的填充被剝掉。 有些函式庫（尤其是 URL-safe 變體）會丟掉結尾的「=」字元，讓字串在查詢參數裡比較好用。嚴格解碼器可以設成接受無填充輸入，或把填充加回去；寬鬆解碼器則會默默產出被截斷、或位移了一個位元組的輸出。
用錯字母表。 RFC 4648 §4 定義帶 + 與 / 的「標準」Base64，而 §5 定義帶 - 與 _ 的「URL-safe」Base64。用其中一套字母表編碼的字串看起來有效，在另一套底下解碼卻會變成垃圾。
位元組被解讀成錯誤的文字編碼。 解碼後的位元組若當 Windows-1252 或 Mac Roman 解讀，只要原文含有 ASCII 以外的任何東西，就會產生亂碼。除非你有特定理由不這麼做，否則一律把解碼後的位元組當 UTF-8 解讀。
把 Base64 當成加密。 任何人拿到字串都能解碼。它是傳輸編碼，不是機密機制。用它來安全運送，不要用來保護祕密。
用換行折行。 電子郵件 MIME 與 PEM 風格的編碼器會把輸出以每行 76 個字元換行。解碼器必須先忽略換行，再把字母表字元重新接起來。
真實世界裡你會在哪裡看到 Base64
你碰到已解碼的 Base64 字串，比想像中更常。JSON Web Token 的 payload，在標頭與簽章被剝掉之後，是 Base64 編碼的 JSON。以 data:image/png;base64, 開頭的 data: URI，把整張圖片當成 Base64 字串承載。Basic HTTP 驗證標頭的值來自 base64(username:password)。電子郵件附件經 SMTP 以 MIME 編碼區塊傳送。多數接受二進位 blob 的 API 會把它們當成 JSON 字串裡的 Base64 接收，因為另一條路——在 JSON 字串字面量裡跳脫位元組——又長又容易出錯。解碼以上任何一種時，上方逐步演練的同一套規則都適用：四個 Base64 字元進去，三個位元組出來，填充處理剩餘。
單一 Base64 解碼範例只是健全性檢查；六個、從單一位元組到四位元組表情符號，才是能用的心智模型。把上方任何一對丟進 Base64 編碼／解碼工具，你會立刻看到解碼文字出現——沒有伺服器、沒有上傳、不必註冊。若你需要字母表與填充規則隨時可查，Base64 解碼速查表把索引表、位元分組規則與長度公式放在同一頁。
若要更深入了解，見 Base64 轉十六進位批次：在本機處理大型輸入。