Base64 與十六進位轉換器可在 RFC 4648 Base64 與 Base16 十六進位之間轉換相同的位元組序列，因此以其中一種形式表示的承載資料可以在另一種形式中精確重現。兩種編碼都是原始位元組的可逆表示法，而非安全性轉換：Base64 將三個輸入位元組打包成四個字元，取自包含 A–Z、a–z、0–9、+、/ 的 64 個符號字母表，而十六進位則將每個位元組寫成取自 0–9 與 a–f 的兩個位數。嚴格的轉換器會驗證規範化填補，拒絕非零的填補位元，且在標準設定檔下絕不接受 base64url 或 MIME 換行，因為猜測設定檔可能會隱藏輸入錯誤，並破壞與簽署資料、協定固定值或快取鍵的精確比對。此工具讀取一端的規範化填補形式，並在另一端輸出等效的小寫十六進位，位元組界線保持明確，因此單一的前導 0x00 位元組會被保留，而不是被捨棄。一切都在瀏覽器內的數值位元組陣列上執行，因此單一轉換是一個確定性的往返：貼上輸入，取得等效表示法，然後複製精確的輸出而不重新格式化。
這項工作刻意設計得很窄。規格以一種表示法交給你位元組，鏈中的下一個工具則預期另一種表示法，問題在於來源實際使用的是哪個字元集。一旦確定，轉換本身是一個確定性、可逆的步驟，不會將位元組解讀為文字、數字、JSON、影像或檔案。
兩種編碼的比較
Base64 與十六進位皆對原始位元組進行編碼，但兩者最佳化的目標不同。十六進位以大小為代價換來對人類的友善性；Base64 則以必須解釋填補、字母表與 URL 變體為代價換來精簡。同時處理兩者的轉換器必須分別保有各自的規則，因為這兩種表示法不可互換，且一方的規則並不適用於另一方。
| 特性 | RFC 4648 Base64 | Base16 十六進位 |
|---|---|---|
| 字母表大小 | 64 個字元 (A–Z、a–z、0–9、+、/) | 16 個字元 (0–9、a–f，輸入大小寫不拘) |
| 每字元的位元數 | 6 | 4 |
| 每字元群組的位元組數 | 3 個位元組產生 4 個字元 | 1 個位元組產生 2 個字元 |
| 填補 | 一個或兩個結尾 = 字元以填滿 4 字元量子 | 無；缺少位數將被拒絕 |
| 輸出大小與輸入的比較 | 約為位元組長度的 4/3，無條件進位 | 恰好為位元組長度的 2× |
| 規範形式 | 長度為 4 的倍數，必需的 =，零填補位元 | 每個位元組兩位數，無 0x，無分隔符，小寫輸出 |
這個比例正是 Base64 在凡是需要精簡的地方佔優勢，而十六進位在凡是需要位元組界線、前導零或人工檢查的地方佔優勢的原因。同樣的三個位元組輸入，也就是 foo 這個字，在 Base64 中輸出為 Zm9v，在十六進位中輸出為 666f6f，而底層的位元組序列 0x66 0x6f 0x6f 完全相同。這個單一範例說明了 base64 十六進位轉換器的整個 API 介面：相同的位元組可以用任一方式寫出，且任一表示法都不會隱藏其底層值。
在 Base64 與十六進位之間轉換
Base64 轉十六進位轉換器在瀏覽器中執行雙向轉換，驗證規範形式，並複製精確的輸出。將整個流程視為三個具體決定，而非單一點擊：方向、來源設定檔，以及如何驗證結果。
- 選擇方向並識別來源設定檔。若來源是規範化填補的 Base64，請選擇 Base64 → 十六進位；若來源是連續的兩位數位元組，請選擇 十六進位 → Base64。確認來源實際使用的是標準 RFC 4648 Base64，而非 base64url (會將 + 與 / 替換為 - 與 _) 也非 MIME (會加上 76 字元的換行)。若設定檔錯誤，請先以其自身的規則進行轉換。
- 貼上規範化輸入，不要附加任何多餘內容。對於 Base64，字串長度必須是四的倍數，以必要的 = 或 == 填補結尾，僅包含 A–Z、a–z、0–9、+、/，且不包含空白字元。對於十六進位，貼上連續的兩位數位元組，無 0x 前綴，無空格，無冒號，無底線，且無奇數的尾端半位元組；0f 是一個位元組，單獨的 f 是不完整的，將會被拒絕。
- 執行轉換，然後驗證位元組計數與前導零。輸出即為精確的等效表示法。在複製之前，請合理性檢查位元組長度：每對十六進位位數代表一個位元組，每四個 Base64 字元解碼為三個位元組 (兩個對應 =、一個對應 ==，且轉換器會拒絕在原本已完整的最終群組上出現 =)。十六進位中的前導 00 是真實的位元組，必須在往返中保留；若來源含有，輸出端也必須含有。
- 複製精確的轉換值。複製動作僅回傳轉換值本身，無標籤、前綴或註解，因此可直接貼入下一個工具而無需重新格式化。若輸入格式錯誤，轉換器會回傳特定錯誤且無部分結果，而非靜默輸出解析器所能解析的任何內容。
為何嚴格的規範驗證很重要
寬鬆的 Base64 解碼器會樂於接受同一個位元組序列的多種拼法。Zm9v 的規範形式、Zm9v=== 帶有額外填補的形式，以及一個假想的最後六個填補位元非零的非規範形式，皆可解碼為 foo。這種彈性在休閒用途時沒問題，但當位元組是簽章、快取鍵、JWT 承載資料，或是與規格逐字元比對的值時，這種彈性就很危險。兩個接受不同規範形式的解碼器可能產生相同的位元組，卻在文字表示法上意見分歧，這會破壞日誌 grep、等值檢查與簽署承載資料驗證。
Base64 轉十六進位轉換器刻意採嚴格作法：它解碼 Base64 輸入，然後重新編碼結果並比較兩種文字形式。任何不符之處 — 額外的 = 填補、在已完整的最終群組上出現 =、或非零的填補位元 — 皆會以特定錯誤拒絕且無部分輸出。十六進位端以同樣方式嚴格：每個位元組兩位數、無分隔符、無 0x 前綴，且對奇數尾端半位元組採硬性拒絕。結果是相同的位元組在任一方向上都會產生相同的字串，而這正是當目標是比較或儲存該值而不僅僅是檢視它時所需要的。
基於同樣的理由，轉換器不會靜默接受 base64url。Zm9v 在兩種設定檔中完全相同，但 -m9v 或無填補的 Zm9v 是 base64url，而非標準 Base64。若來源確實是 base64url，請先使用具 base64url 感知的解碼器在該設定檔下轉換，然後再將規範化填補的輸出餵入此處。將設定檔偵測視為獨立步驟，可讓輸入錯誤顯而易見，而非�藏在一次成功的轉換背後。
必須先識別的設定檔
在開啟轉換器之前，請先決定來源實際使用的是哪個設定檔。兩者容易混淆，因為字母表有所重疊，但它們對兩個字元與填補的規則不同。規格 RFC 4648 將標準 Base64 (第 4 節) 與 base64url (第 5 節) 定義為不同的設定檔，且許多工具與協定會再加上自身的換行。
| 設定檔 | 字母表與分隔符 | 填補 | 使用於 |
|---|---|---|---|
| RFC 4648 標準 Base64 | A–Z、a–z、0–9、+、/ | 必需的 = 以填滿 4 字元群組 | 電子郵件附件、一般協定欄位、本工具 |
| base64url (RFC 4648 §5) | A–Z、a–z、0–9、-、_ | 通常省略 | JWT、JWS、URL 路徑、檔名 |
| MIME Base64 | 標準字母表加上 76 字元處的 \r\n 換行 | 必需的 = | 電子郵件本文、部分舊式編碼器 |
| 嚴格十六進位 (Base16) | 0–9、a–f (或 A–F) | 無；每個位元組兩位數 | 雜湊值、二進位 ID、十六進位傾印、本工具 |
實務上的規則：若來源含有 + 或 /，則為標準；若含有 - 或 _，則為 base64url；若含有換行，則為 MIME 風格。在將值餵入轉換器之前，請先去除換行並重新填補，之後的工作流程就會是單一的確定性步驟，而非一連串的猜測。
限制、隱私與本工具不會做的事
轉換器在瀏覽器內的數值位元組陣列上運作，絕不會上傳輸入。對於不應離開本機的值來說這點很重要，但這並不會將 Base64 或十六進位變成一種安全性控制。兩者都是可逆的編碼，而非加密、雜湊、簽章或存取控制。透過本工具複製的憑證、權杖或私密金鑰在進入時是什麼秘密，離開時仍是相同的秘密，且本工具不會就此提出警告。請將敏感性值排除在不受信任的剪貼簿、日誌、螢幕擷圖與共用瀏覽器工作階段之外，並將任何一次成功的轉換視為語法檢查，而非承載資料的語意驗證。
兩個硬性限制決定了本工具能做的事。首先，解碼後的輸入上限為 500,000 位元組，以限制瀏覽器記憶體與輸出大小。其次，轉換器不會解讀位元組：它不會新增 MIME 標頭、data: URL、換行或檢查碼欄位，也不會將結果剖析為 UTF-8、JSON、憑證或影像。若周邊的應用程式預期上述任一種容器，請將轉換後的位元組視為其中一層，並分別驗證容器。格式錯誤的輸入一律回傳特定錯誤且無部分結果，因此貼上失敗是一個清楚的訊號，代表應重新檢查設定檔、填補與位數，而非靜默截斷。
何時 Base64 十六進位轉換器是合適的工具
當規格以一種形式交給你位元組，且下一步預期另一種形式，而該值的大小足以容納在 500,000 位元組之內時，請使用 Base64 轉十六進位轉換器。典型的情境包括協定欄位檢查、將簽署承載資料與已發布的測試向量進行比對、從 Base64 樣本建構十六進位字面值、產生確定性的快取鍵，以及在不同慣例撰寫的測試固定值之間轉換。如需了解嚴格驗證旨在防範的位元組層級錯誤的背景，如何在不犯錯的情況下將 base64 轉換為十六進位指南以額外範例說明相同的規範化規則。
對於安全性敏感的協定，請將一次成功的轉換視為必要而非充分的條件：轉換證明位元組可在表示法之間精確往返，而實際的語意仍須符合主導規格或官方測試向量。此工具是精確的轉換器，而非驗證器，兩者角色的差異正是「位元組相等」與「位元組的意義符合協定所述」之間的差別。
如需更深入的探討，請參閱將編碼轉換為 UTF-8：十六進位、十進位與二進位。