Base64 與十六進位之間的轉換，是同一份資料在兩種可逆文字編碼之間的直接逐位元組對譯：每三個輸入位元組會變成四個 RFC 4648 Base64 字元，而每個輸出位元組則會恰好變成兩個小寫十六進位數字。兩者之間的轉換純粹只是表示法的改變，並非語意上的改變：輸入位元組與輸出位元組完全相同，差別只在於每個位元組在畫面上的書寫方式。正因為如此，這種轉換是無損、精確且可逆的；只要能正確處理位元組邊界的工具，就能作為不同編碼方言之間可靠的橋樑，無論是通訊協定、測試固定資料或偵錯工具都能互通。
這種對應之所以成立，是因為兩種編碼都基於同一個基本單位——八位元的位元組。Base64 把位元組重新分組為四個字元的量子，從由大寫字母、小寫字母、數字、加號與斜線組成的標準字母集中選取，等號則只用於在最後一個不完整的量子後補齊。十六進位（又稱 Base16）則保留位元組邊界，每個位元組以兩個數字表示，因此像 foobar 這樣的 6 位元組值會呈現為 12 個字元的字串 666f6f626172，而其標準的 Base64 形式則是 Zm9vYmFy。掌握這種逐位元組的對應關係，是任何安全轉換的基礎。
Base64 與十六進位實際代表的意義
Base64 是由 RFC 4648 定義的定位編碼，它把輸入視為一串位元組，將其位元串接起來，再切割成若干個六位元的群組。每個六位元群組會對應到 64 個可列印 ASCII 字元中的一個。由於三個輸入位元組包含 24 個位元，因此三個位元組剛好產生四個六位元群組，也就是四個輸出字元且無餘數。當輸入長度不是三的倍數時，最後一個群組會以零位元補齊，並附加一個或兩個等號，使每行輸出長度維持為四的倍數。
十六進位（又稱 Base16）則更為單純。每個輸入位元組會被切成兩個四位元的半位元組，每個半位元組以 0 到 9 以及 a 到 f（或大寫）中的一個字元書寫。由於每個位元組永遠剛好是兩個字元，編碼後的字串中位元組邊界清晰可見。沒有填補、沒有大小寫的字母變體，也不需要換行——每個位元組都各自獨立呈現。
因此，這兩種編碼是互補而非競爭的關係。Base64 大約精簡 33%，這正是它被用於在電子郵件、JSON Web Token 與資料 URL 等文字通道中嵌入二進位資料的原因。十六進位的大小約為原始位元組的兩倍，但能讓讀者逐位元組肉眼判讀，這也是通訊協定規格、雜湊輸出與封包擷取傾向採用它的原因。
為何這兩種編碼如此契合
Base64 與十六進位共享一個關鍵特性：輸入的每個位元組都能完整往返。不進行壓縮、不產生校驗和、不進行加密，也不會把位元組值解讀為字元、數字或其他任何意義。正是這個共通特性，讓轉換工具能安全地作為不同文字表示法系統之間的轉譯層。
兩者在兩個重要面向也有所不同。第一，Base64 會跨位元組邊界重新組織位元，因此讀者無法單看四個 Base64 字元就指出它們來自哪三個輸入位元組，必須經過解碼。十六進位則保留位元組邊界，這也是十六進位輸出更容易以肉眼檢查、偵錯工具與雜湊輸出普遍採用它的原因。第二，Base64 有填補規則，十六進位則沒有。標準的 Base64 字串長度必須是四的倍數，並以零個、一個或兩個等號結尾。嚴格的十六進位字串長度則必須是二的倍數，不含前置字元、分隔符或空白。
| 特性 | RFC 4648 Base64 | Base16 十六進位 |
|---|---|---|
| 每個位元組的輸出字元數 | ≈ 1.33（每 3 位元組 4 字元） | 2 |
| 字母集 | A–Z、a–z、0–9、+、/ | 0–9、a–f（或 A–F） |
| 填補 | 僅在結尾使用等號 | 無 |
| 位元組邊界可見 | 否 | 是，每兩個數字一組 |
| 相較原始位元組的大小開銷 | 約 33% | 100% |
| 標準長度規則 | 四的倍數 | 二的倍數 |
Base64 轉十六進位工具如何處理您的輸入
Base64 轉十六進位工具直接實作了 RFC 4648 Base64 的四字元量子與 Base16 的兩位數位元組。轉換過程以數值位元組陣列進行，而非透過瀏覽器的文字強制轉型，這表示位元組本身絕不會被重新解讀為 UTF-8、解碼為 JSON，或在中途以其他方式轉換。整個轉換過程在本機瀏覽器中執行，輸入資料不會離開您的電腦，也無需上傳。
Base64 方向採用刻意的嚴格規則。輸入長度必須是四的倍數，所有必要的等號都必須存在，填補只允許出現在結尾，不忽略空白字元，且每個字元都必須屬於由大寫字母、小寫字母、數字、加號與斜線組成的標準字母集。解碼之後，轉換工具會重新編碼產生的位元組，並拒絕任何填補位元不為零的輸入，因為那些非零的填補位元會產生同一份資料的第二種非標準拼法。這種嚴格性，正是輸出在比對簽署資料、快取鍵或協定固定資料時值得信賴的原因。
十六進位方向同樣嚴格。輸入必須是每個位元組對應兩個數字的連續序列，不接受 0x 前置字元、沒有分隔符、不含空白、不含底線，也不能出現奇數的尾端半位元組。大寫與小寫數字皆可接受，但輸出永遠為小寫以維持一致的精簡形式。像是 f 這種單一字元會被拒絕，因為它並非完整的位元組；最小有效的十六進位輸入是像 0f 這樣的兩個數字。
三步驟完成 Base64 與十六進位的轉換
- 選擇符合資料來源的方向。若來源是標準填補的 Base64，請選擇 Base64 轉十六進位；若來源是嚴格的兩位數十六進位，則選擇十六進位轉 Base64。同時，請確認來源確實使用標準的 RFC 4648 Base64——而不是以連字號與底線取代字元的 base64url，也不是帶有換行的 MIME 變體。
- 貼上乾淨的輸入。對於 Base64，請貼上不含任何空白、換行或引號的標準填補字串。對於十六進位，請貼上每個位元組剛好兩個數字的連續字串，不含 0x 前置字元、空格、逗號，也不可有多餘的尾端字元。不符合這些規則的內容將會被轉換工具拒絕。
- 執行轉換並驗證結果。請確認位元組長度符合預期——六個位元組的輸入應產生 12 個小寫十六進位字元或 8 個 Base64 字元，視方向而定——並確認任何前導零位元組都正確顯示為十六進位的 00，而非被悄悄捨去。然後複製精確的輸出。
引用 RFC 4648 測試向量中的實際範例，能讓位元組對應更具體。ASCII 字串 foobar 編碼為標準的 Base64 字串 Zm9vYmFy。將該 Base64 送入轉換工具後，會產生小寫十六進位字串 666f6f626172，正好就是 ASCII 的六個位元組以兩個數字為單位書寫而成。將 666f6f626172 再經由十六進位轉 Base64 的方向送回，會重現 Zm9vYmFy。位元組序列從未改變，改變的僅是表示法。
工具刻意拒絕的格式設定
有幾種廣泛使用的變體並不被本工具接受，而這是刻意設計的特性而非限制。用於 JSON Web Token 與許多網頁 API 的 Base64url，將 + 替換為 -、將 / 替換為 _，且常省略填補。MIME 風格的 Base64 則以 76 字元為單位進行換行，並使用不同的標頭集。部分命令列與電子郵件解碼器可容忍空白、接受未填補的輸入，或將 = 視為一般字元。
本工具不會悄悄接受上述任何一種，因為猜測格式可能掩蓋輸入錯誤。在三種不同的格式假設下都能成功解碼的字串，並無法指出實際採用的是哪一種解讀。透過要求標準填補的 Base64 與連續兩位數的十六進位，本工具迫使您在轉換前明確指定格式，而這在依據書面規格作業時，幾乎永遠是較安全的選擇。
無需自我懷疑地驗證輸出
每次轉換之後，請在信任結果前執行兩項快速檢查。首先，比對位元組長度。十六進位字元數除以二必須等於解碼後的位元組數；Base64 字元數（不含結尾等號）乘以三再除以四，必須四捨五入到相同的數量。若不一致，代表輸入並非您以為的內容，即使轉換工具沒有拋出錯誤。
其次，留意前導零位元組。像是 0x0a 這種單位元組值，會成為十六進位字串 0a，而非 a；輸入中的任何前導零都必須在十六進位輸出中以 00 呈現。許多手寫的轉換腳本在往返經過會捨棄前導字元的文字型別時，會遺漏這些零。快速目視檢查前幾個位元組，就能確認沒有任何前導零被捨去；而對於安全性敏感的協定，結果仍應比對相關規格或官方測試向量，而非僅視為語意上的驗證。
不該使用轉換的場合
Base64 與十六進位都是可逆的編碼方式，並非加密、雜湊、簽章、壓縮、認證或存取控制。在 Base64 與十六進位之間轉換憑證、權杖、私鑰、個人資料或秘密，並不會以任何方式保護它們，轉換後的形式與原本一樣敏感。請將敏感性資料遠離不受信任的剪貼簿、記錄檔、螢幕截圖、議題追蹤系統、分析欄位與共用瀏覽器工作階段；當需要保密性或認證時，請改用專門設計的工具，例如 AES Encryption Online 頁面。
同時也值得說明本工具不會做的事。它不會把位元組解讀為 UTF-8、數字、憑證、影像、JSON、加密金鑰、校驗和或檔案，也不會加上 MIME 標頭、data-URL 前置字元、換行或校驗和欄位。若目的端需要其中任一種容器——例如 JSON 字串、HTML 資料 URL 或 gzip 串流——請將轉換後的位元組視為一層，並獨立驗證其外層格式。若想深入了解嚴格的驗證規則與何謂標準 Base64，Base64 to Hex Cheat Sheet：RFC 4648 快速參考指南逐步說明了本工具強制執行的字母集、填補與零填補位元規則；而 RFC 4648 規格則是該編碼本身的權威參考。