Base64 和十六進位是同一組原始位元組的兩種可逆編碼，兩者之間的轉換只需要符合 RFC 4648 所定義的嚴格輸入規則即可：一邊是正規化且帶填補字元的 Base64，另一邊是兩位數小寫的十六進位。Base64 轉 Hex 轉換器完全在您的瀏覽器中處理這項轉換，會先驗證字母表、位元組邊界、必要的填補字元，以及零填補位元，然後才輸出精確的小寫十六進位或正規化且帶填補字元的 Base64。由於兩種格式代表的是完全相同的位元組，一次成功的來回轉換只能證明輸入的格式正確——它並不會驗證語意、簽章或總和檢查碼，也不提供任何機密性。本速查表將您實際需要的規則集中在一處：什麼算作正規化且帶填補字元的 Base64、什麼算作有效的十六進位、如何辨識常見的小陷阱（缺少 '=' 填補、大寫十六進位、奇數個十六進位數字、base64url），以及在頁面上應確切遵循哪些步驟。當您處理通訊協定測試資料、快取鍵、雜湊摘要、已簽章的酬載，以及無論您目前工具預期採用哪種表示法而交給您的二進位識別碼時，請將此頁保持開啟。
速查表一覽
兩種格式都將原始位元組編碼為可列印的 ASCII 文字，因此任何位元組序列在各自格式中都只有一種正規化表示法。下列差異說明了為何其中一種比另一種更易於肉眼閱讀或嵌入程式碼。
| 屬性 | Base64 (RFC 4648) | Base16 十六進位 |
|---|---|---|
| 每字元的位元數 | 6 | 4 |
| 每位元組的字元數 | 每 3 位元組 4 字元 (~1.33) | 2 |
| 字母表大小 | 64 | 16 |
| 字元集 | A–Z、a–z、0–9、+、/ | 0–9 以及 a–f（輸入可為 A–F） |
| 填補字元 | =（結尾一個或兩個） | 無 |
| 長度訊號 | 結尾的 = 表示最後一組較短 | 始終為偶數個數字 |
| 大小寫敏感性 | 大小寫屬於字母表的一部分 | 輸入不區分大小寫；輸出為小寫 |
| 可逆回相同位元組 | 是 | 是 |
| 提供機密性或身分驗證 | 否 | 否 |
| 不得靜默接受的變體 | base64url、MIME 換行、不帶填補 | 0x 前綴、分隔符、結尾奇數半位元組 |
最值得記住的一個數字：4 個 Base64 字元永遠代表 3 位元組，因此 (Base64 長度 ÷ 4) × 3，再減去 '=' 填補字元的數量，即可得出位元組數。對於十六進位而言，每 2 個字元正好是 1 位元組。
能抓出所有錯誤的輸入規則
轉換器在兩端刻意保持嚴格，因為猜測設定檔可能會掩蓋真正的輸入錯誤。在您貼上任何內容之前，請逐步檢視以下清單：
- Base64 方向：字串長度必須為 4 的倍數，僅能包含 A–Z、a–z、0–9、+、/ 以及 =，且 = 字元只能出現在最末端。空白、換行，以及 base64url 的連字號或底線都會被拒絕。
- 十六進位方向：每個位元組必須正好是 0–9 以及 a–f（或 A–F）中的兩個字元。不接受 0x 前綴、空格、冒號、底線，也不接受結尾的單一數字。單獨一個 "f" 是不完整的，解析器會拒絕它。
- 填補位元檢查：當最後一組 Base64 只有一個或兩個位元組時，剩餘的 6 位元或 12 位元位置必須為零。如果不是零，則相同位元組會有第二種非正規化的拼法，轉換器會將其拒絕，而不是靜默地選擇其中一種。
- 長度檢查：預期的位元組數是轉換之後的第一項健全性檢查。如果規格規定為 32 位元組，您應該看到 32 位元組——64 個十六進位字元，或 44 個 Base64 字元加上一個 '='。
這些規則在比較已簽章的資料、通訊協定測試資料、快取鍵，或精確的序列化值時最為重要——在這些情境中，「幾乎相同」並不等於相同。
逐步將 Base64 轉換為 Hex
每當某個工具或規格交給您一段 Base64 字串，而下一步預期接收十六進位位元組時，請使用以下程序。
- 確認輸入為標準的 RFC 4648 Base64：A–Z、a–z、0–9、+、/，且 '=' 填補只能出現在結尾，不得包含空白。
- 開啟 Base64 轉 Hex 轉換器，並選擇 Base64 轉十六進位方向。
- 將 Base64 字串原樣貼上，不要有前後空白或換行。
- 執行轉換，並讀取輸出旁顯示的位元組長度。將其與規格或來源所預期的長度進行比對。
- 檢查十六進位結果中是否有前導 00 位元組——當位元組透過其他文字工具複製時，這些位元組很容易遺失。
- 複製十六進位結果並貼到下一個工具中。如果下游步驟預期使用 0x 前綴、空格或大寫，請在該步驟自行加上；轉換器刻意輸出精簡的小寫格式。
逐步將 Hex 轉回 Base64
當來源是十六進位位元組，而接收端工具預期接收正規化且帶填補字元的 Base64 時，請使用以下程序。
- 移除十六進位輸入中所有的 0x 前綴、空白、冒號或底線。轉換器不接受這些格式。
- 確認剩餘字串包含偶數個字元——每個位元組正好是兩個十六進位數字。
- 開啟轉換器，並選擇十六進位轉 Base64 方向。
- 貼上清理過的十六進位字串，然後執行轉換。
- 確認 Base64 輸出長度可被 4 整除，並以 0、1 或 2 個等號結尾。字串中間不允許出現填補字元。
- 複製正規化的 Base64 字串。如果您的下一個工具預期使用 base64url 或不帶填補的 Base64，請明確地執行該轉換——不要假設轉換器會自動為您處理。
解讀 RFC 4648 測試向量
RFC 4648 定義了一小組正規化的測試向量，任何合規的轉換器都必須重現這些結果。手動逐一處理是建立規則直覺的最快方式。以六位元組的 ASCII 字串 "foobar" 為例：
- 位元組的十六進位表示：66 6f 6f 62 61 72（六個位元組，十二個十六進位字元）。
- 重新組合為 48 位元資料流：01100110 01101111 01101111 01100010 01100001 01110010。
- 分割成六位元區塊：011001 100110 111101 101111 011000 100110 000101 110010——八個索引，八個 Base64 字元。
- 將每個索引對應到 Base64 字母表：25→Z, 38→m, 61→9, 47→v, 24→Y, 38→m, 5→F, 50→y。
- 最終的 Base64：Zm9vYmFy——不需要填補，因為六個位元組正好構成兩個完整的 24 位元群組。
完整的 RFC 4648 向量集合（轉換器已針對其進行驗證）如下所示：
| 輸入位元組 | 長度（位元組） | 十六進位 | Base64 |
|---|---|---|---|
| (空) | 0 | (空) | (空) |
| f | 1 | 66 | Zg== |
| fo | 2 | 666f | Zm8= |
| foo | 3 | 666f6f | Zm9v |
| foob | 4 | 666f6f62 | Zm9vYg== |
| fooba | 5 | 666f6f6261 | Zm9vYmE= |
| foobar | 6 | 666f6f626172 | Zm9vYmFy |
若要自行測試某個工具，請將任一列的 Base64 貼入轉換器並確認十六進位結果相符；接著再貼回十六進位，確認 Base64 與正規化拼法完全一致。如需進一步了解正規化位元組與嚴格驗證的背景，請參閱關於取得精確 RFC 4648 位元組的指南。
安全限制與本工具不會執行的操作
編碼不等於加密。Base64 和十六進位都會將輸入的位元組原樣暴露，因此轉換憑證、權杖、私鑰或個人資料並無法加以保護——請勿將敏感值放入共用的剪貼簿、螢幕擷圖、問題追蹤系統、分析欄位或不受信任的瀏覽器工作階段中。轉換器完全在您的瀏覽器中執行，絕不會上傳您的輸入，並使用數值型位元組陣列而非文字強制轉換，以避免靜默截斷或字元重新解讀。
以下三項具體限制規範了它所能接受的內容：
- 大小上限：輸入上限為 500,000 個解碼後位元組，以確保瀏覽器記憶體與輸出大小在可預期範圍內。
- 不進行解讀：位元組不會被解析為 UTF-8、數字、憑證、影像、JSON、加密金鑰、總和檢查碼或檔案。系統不會加上 MIME 標頭、data-URL 前綴、換行符或總和檢查碼結尾。
- 精確輸出：格式錯誤的輸入會產生特定的錯誤訊息，且不會產生部分結果。輸出絕不會被靜默截斷，十六進位永遠是小寫，而 Base64 永遠是標準且帶填補的 RFC 4648 格式。
對於通訊協定欄位與已簽章的資料，請將最終表示法與其管轄規格或官方測試向量進行比對，而非將一次成功的轉換視為語意上的驗證。編碼僅能證明位元組在來回轉換中得以保留——這些位元組的意義仍需另行檢查。