Base64 to Hex Converter 是一款免費、無需註冊的工具，可在您的瀏覽器內部完全在本地將相同的位元組序列在標準 RFC 4648 Base64 與小寫十六進位之間互相轉換，無需建立帳號、無需安裝、無需 API 金鑰，也無需上傳您所貼上的位元組。您只需開啟頁面、選擇方向、貼上數值，然後複製精確的結果；任何內容都不會離開目前的分頁。轉換作業鎖定在八個 RFC 4648 測試向量上——空序列加上標準的 f、fo、foo、foob、fooba 與 foobar 案例，以及一個涵蓋字母表數值 62 與 63 的序列——因此一次成功的來回轉換能證明底層位元組確實相符，而非僅僅表面上相似。解碼器還會將產生的位元組重新編碼，以拒絕任何非零的填補位元，這能避免同一筆資料的第二種非標準拼寫方式蒙混過關。輸入上限為 500,000 個已解碼位元組，以維持頁面的回應速度；超出此範圍時，轉換作業會直接停止，而不會默默截斷您已產生的內容，且複製按鈕僅會回傳轉換後的數值，永遠不會夾帶標籤或說明文字。
無需註冊、無需安裝：這對編碼後的位元組代表什麼意義
編碼後的字串很少單獨出現。它們常附掛於日誌、簽章後的承載資料、JWT 區段、快取鍵、協定測試資料、雜湊摘要，以及二進位識別碼之上，而且往往夾帶工作階段權杖、內部主機名稱、線上環境的測試資料，或根本不該流入第三方資料庫的數值。一個標榜「免費」卻暗中要求電子郵件地址、電話號碼或 Google 登入的工具，對該類工作量而言其實並不真的免費——每一次貼上都變成一道問題：所選的服務商是否會儲存這些位元組、記錄下來，或將其導入數據分析流程。
Base64 to Hex Converter 在設計上便迴避了這個問題。該頁面是單一的靜態文件，解析與轉換皆透過 JavaScript 直接處理數值型位元組陣列，而非透過任何文字強制轉型的捷徑，且網路監控面板對輸入內容顯示零對外流量。沒有註冊表單、沒有驗證碼、沒有限速的匿名層級、不需要電子郵件驗證，也沒有任何需要以瀏覽器擴充功能形式安裝的東西。500,000 位元組上限僅是用來限制瀏覽器記憶體，並非付費牆。這種定位讓本工具適用於複製已簽署權杖的 CTF 籌辦者、讀取第三方 API 欄位的後端工程師，或在不想臨時寫腳本的情況下檢查雜湊值的資安分析師。
在瀏覽器中將 Base64 轉為十六進位
實際操作流程很短，且完全不會離開您所開啟的頁面。請依序執行下列步驟：
- 在任何現代的桌上型或行動瀏覽器中開啟 Base64 to Hex Converter；頁面以單一文件形式載入，於顯示出來的瞬間即可使用，無需安裝步驟，也沒有註冊表單擋住輸入區域。
- 選擇符合您來源資料的方向。當輸入為帶有標準填補的 RFC 4648 Base64 時，請選擇「Base64 轉十六進位」；當輸入為連續的兩位數位元組數值串流時，請選擇「十六進位轉 Base64」。
- 將來源字串貼入輸入區域。對於 Base64 而言，代表的是不帶空白、不換行、字元僅來自標準字母表（A–Z、a–z、0–9、+、/），且等號僅在結尾作為必要填補的標準化文字。對於十六進位而言，則代表每個位元組恰好兩位數字、無 0x 前置符號、無分隔符號、無底線、無內嵌空白，且總長度為偶數。
- 執行轉換。頁面會檢查預期的位元組長度、依據所選字母表驗證每一個字元，並在輸入格式錯誤時回報一個明確的錯誤訊息，而不會產生部分結果。輸出內容絕不會被默默截斷。
- 驗證輸出結果。確認位元組長度符合您的協定預期，確認前導零位元組在十六進位中顯示為 00，然後再使用專屬的複製按鈕將精確數值複製到剪貼簿。
嚴格轉換器強制執行的輸入規則
嚴格的驗證機制讓本頁面得以標榜「精確到每個位元組」，而非「通常精確」。在 Base64 方面，輸入長度必須為 4 的倍數、每個字元皆須來自標準字母表、必要的等號填補必須存在、填補僅能出現於結尾，且空白字元會被拒絕而非默默忽略。解碼器還會將產生的位元組重新編碼，並拒絕任何非零的填補位元，這能抓出同一筆資料的第二種非標準拼寫方式——也就是簽章驗證器與精確比對快取鍵必須避免的那種拼寫。
在十六進位方面，解析器要求每個位元組恰好兩位數字、接受大寫或小寫的輸入數字，並輸出一致性較佳的小寫格式。數值 0f 代表一個位元組（十進位 15），而單獨的 f 則是不完整的位元組，會遭到拒絕——這在讀取含有前導零的協定欄位（例如 00 01 02 03）時正是您想要的行為。結尾出現奇數半位元組、內嵌空格、0x 前置符號，或位元組之間出現底線的情況，也都會被拒絕，以避免在複製貼上的過程中位元組界線悄悄位移。
| 方向 | 接受的形式 | 常見遭到拒絕的形式 |
|---|---|---|
| Base64 → Hex | 長度為 4 的倍數；僅限 A–Z、a–z、0–9、+、/；必要的 = 僅能出現於結尾 | 換行、缺少填補、base64url 的連字號或底線、內嵌空白、字母表錯誤 |
| Hex → Base64 | 每個位元組恰好兩位十六進位數字；數字可為大寫或小寫；總長度為偶數 | 0x 前置符號、位元組之間的冒號或空格、底線、結尾的奇數半位元組 |
此表格摘要了 RFC 4648 中所記錄的嚴格性契約；每一列所反映的規則都是頁面對每次轉換實際套用的規則，而非僅僅是理想中的功能。
Base64 與十六進位在位元組層級的比較
兩種編碼皆代表相同的位元組序列——在語意上既沒有哪一種比較「安全」，也沒有哪一種比較「精簡」——但兩者的實際特性有所不同。下表依據 RFC 4648 的定義，精確比較這兩種表示方式，這也是本轉換器嚴格規則的基礎。
| 特性 | RFC 4648 Base64 | Base16 十六進位 |
|---|---|---|
| 每個輸入位元組的輸出 | 平均約 1.33 個字元（每 3 位元組 4 個字元） | 恰好 2 個字元 |
| 字母表 | A–Z、a–z、0–9、+、/，外加 = 填補 | 0–9 與 a–f（輸入接受 A–F） |
| 填補 | 必要的 = 將長度補到 4 的倍數 | 無填補；輸入本身必須已是偶數位數 |
| 大小寫敏感度 | 區分大小寫（A 與 a 為不同的值） | 輸入不區分大小寫；輸出為小寫 |
| 位元組界線 | 以 3 位元組為一組計算；於文字中不可見 | 每 2 位數字即明確標示 |
| 相較於原始位元組的額外成本 | 約增加 33% | 恰好增加 100% |
| 使用本轉換器的來回轉換 | 可，須有必要的填補且填補位元為零 | 可，輸出為小寫標準格式 |
若想看這些規則套用於單一標準向量的範例，可取兩個位元組的序列 fo——位元組 0x66 後接位元組 0x6F。將 16 個位元讀為 01100110 01101111，並以 6 位元為一組切分，可得 011001（25 = Z）、100110（38 = m），以及 111100 加上兩個零填補位元（60 = 8）。這兩個未使用的填補位元為零，這是嚴格解碼器唯一接受的拼寫方式，因此標準的 Base64 形式為 Zm=。十六進位形式則單純為 666f，每個位元組各佔兩位數字。雙向的參考資料已彙整於 Base64 to Hex 重點速查表：RFC 4648 快速參考。
嚴格解碼器不會擅自猜測的格式變體
數個相關的格式刻意設計為不可互通，且轉換器拒絕在它們之間進行猜測，因為猜測可能會掩蓋輸入上的錯誤。標準的 RFC 4648 字母表使用加號與斜線，且需要填補；base64url（許多網頁 API 與 JWT 函式庫所輸出的格式）則將加號替換為連字號、斜線替換為底線，且經常省略等號。像 Zm-8 這樣的字串看似正確，卻屬於不同的格式變體，因此會遭到拒絕。若您的來源是 base64url，請先在其所屬的格式變體下進行轉換；本頁面不會在您未明確指定的情況下默默替換字母表。
同樣的邏輯亦適用於 MIME 包裝版本的 Base64（其允許在 76 個字元處換行，且可能省略填補），以及接受 URL 安全變體的命令列解碼器。當某份規格以一種表示方式給定位元組，而下游工具卻預期另一種時，最安全的作業流程是：先確認格式變體，再於此處執行轉換，並將產生的位元組長度與前幾個位元組與規範文件比對，而非將一次成功的轉換視為語意上的驗證。
限制與本頁面不會執行的作業
500,000 位元組上限是唯一的硬性輸入限制；超出此限制時，轉換作業會直接拒絕啟動，而不會中途截斷。針對更大的承載資料，Base64 to Hex 批次處理：在本地處理大型輸入 一文說明了套用於更大量工作時的相同限制。除大小上限之外，轉換器的功能刻意保持精簡。它不會將位元組解讀為 UTF-8、JSON、數字、憑證、影像或加密金鑰。它不會添加 MIME 標頭、data-URL 前置字串、換行符號，或校驗和欄位，亦不會嘗試辨識輸入是由哪個應用程式所產生。
本頁面亦不對機密性作出任何承諾。Base64 與十六進位皆為可逆的編碼方式，而非加密、雜湊、簽章、壓縮、認證或存取控制——其輸出所揭露的位元組與輸入完全相同。將憑證、權杖、私鑰或個人紀錄透過本工具進行轉換並無法保護它們；請將本頁面視為放大鏡而非保險箱，並避免將敏感數值置於不受信任的剪貼簿、螢幕擷圖、共用瀏覽器工作階段及問題追蹤系統中。當位元組涉及安全性時，請將最終表示方式與規範文件或官方的測試向量進行比對，而非僅憑「成功」的綠色標示就予以信任。