Base64 編碼 / 解碼
編碼和解碼 Base64、Base64URL、Base32 與十六進位——文字邊輸入邊轉換，檔案可拖放——解碼器夠嚴格，能告訴你第一個不該出現的字元的確切位置，而不是含糊其辭。一切都在你的瀏覽器中執行：人們解碼的字串往往正是權杖和金鑰，把它們送給伺服器、或貼進有紀錄的 AI 對話，正是解碼器絕不能要求你做的事。
檔案
把檔案拖到這個框裡的任意位置，即可按上方所選格式編碼——你會得到編碼後的文字和一個現成的 data URL。也可以把編碼文字貼到這裡，把解碼出的位元組下載為檔案。
四種字母表，同一件事
四種格式做的都是同一件事——只用安全、可列印的字元來書寫任意位元組——只是面向不同的場景。標準 Base64 是電子郵件附件、設定檔和無數 API 的預設選擇。Base64URL 把會破壞 URL 的兩個字元（+ 和 /）換成 - 和 _，並去掉填充，是每個 JSON Web Token 內部使用的字母表——用 JWT 解碼器解開一個權杖，三段全都是這種格式。Base32 使用更小的、不區分大小寫的字母表，能經受朗讀和手工輸入，所以 TOTP 驗證器金鑰用它發放。Hex 讓體積翻倍，換來完全的透明：一位元組、兩字元、無所隱藏——這正是雜湊的格式，雜湊產生器產生它，雜湊識別器辨認它。
這裡的嚴格是有意為之，它正是解碼器和除錯工具的區別。像 atob() 這樣的瀏覽器內建函式，對「第 4 位有個錯字」的字串和「根本不是 Base64」的字串只會擲出同一個籠統錯誤。本解碼器逐字元驗證，報告第一個出錯的位置——從 JSON 裡拖進來的一對引號、本該用 URL 安全字母表卻出現的一個 +、卡在中間的填充、或是最後一個字元溢出的位元不為零（表示字串在編碼之後被改過）。九成「解不開」的謎團，在有人指出那個位置之後就一目了然。又因為這類工作常常涉及憑證——Kubernetes 金鑰就是 Base64（是編碼，從不是加密）、權杖載荷、設定檔裡的金鑰——整個轉換都在本機完成，遵循與 .env 驗證器相同的規則：敏感輸入絕不傳輸。配套文章 Base64 不是加密 更完整地論述了這一區別為何重要。
常見問題
Base64 是一種加密嗎？
不是。Base64 是一種編碼——一種沒有金鑰、沒有保密性的可逆換裝。任何人看到 Base64 字串都能立刻解碼，所以「API 金鑰在設定裡是 Base64 編碼的」就等於「API 金鑰在設定裡是明文」。文章 Base64 不是加密 釐清了編碼、加密與雜湊，以及混淆它們各自會造成的錯誤。
為什麼這個解碼器能告訴我錯誤的確切位置？
因為只說「無效字元」卻不給位置，正是普通解碼器浪費你一下午的方式。貼上的字串通常死於三個原因之一：混入了周圍文字的雜散字元（引號、逗號、一行日誌）、用錯了字母表（把 URL 安全字串餵給標準解碼器）、或者複製時被截斷。這裡會指出第一個出錯的字元及其索引，你可以盯著那個位置看，判斷究竟是哪一種。
Base64 與 Base64URL 有什麼區別？
字母表不同。標準 Base64 使用 + 和 /，它們在 URL 裡是結構字元，所以 URL 安全的 Base64 把它們換成 - 和 _，並且通常去掉 = 填充。每個 JWT 內部用的都是這一種。把一種餵給另一種的解碼器，是在第一個 + 或 / 的位置解碼失敗的最常見原因——本工具把各個模式分開，錯誤訊息才能告訴你發生的正是這件事。
在這裡解碼權杖或金鑰安全嗎？
安全——轉換在你的瀏覽器、在本頁面內執行，你貼上的任何內容都不會被傳輸或儲存。這一點很重要，因為人們解碼的東西往往正是憑證：設定檔裡的 Base64 資料塊、Kubernetes 金鑰（那是 Base64，不是加密——見上一個問題）、權杖的載荷。把同一字串貼進 AI 對話，等於把一份副本傳送給一個有紀錄的第三方系統；見 不要讓聊天機器人碰你的金鑰。
為什麼我的檔案解碼時顯示「不是有效的 UTF-8」？
因為它是二進位——圖片、壓縮檔、任何編譯產物——而二進位不是文字。文字解碼器會拒絕，而不是把亂碼交給你。請用文字框下方的「檔案」區域：把 Base64 貼到那裡，下載位元組完好無損的重建檔案。