Base64 編碼解碼工具
快速進行 Base64 編碼和解碼，支援 UTF-8 文字轉換
選擇轉換方式
什麼是 Base64？
Base64 是一種用 64 個可列印字元表示二進位資料的方法。這 64 個字元包括大小寫字母 A-Z、數字 0-9，以及 + 和 / 兩個符號。因為只使用可列印字元，Base64 編碼後的資料可以安全地在郵件、網頁、JSON 等只支援文字的場景中傳輸。編碼後的資料會比原始資料大約增加 33%。Base64 最早出現在 1987 年的 PEM 協定中，用於在郵件中安全傳輸二進位資料。現在它已成為網際網路標準之一，被廣泛應用於各種場景，從電子郵件附件到 JWT 權杖，從圖片內嵌到資料傳料傳輸。幾乎所有程式語言都內建了 Base64 編解碼功能。
使用方法
使用方法
- 在左側輸入框貼上文字
- 選擇「編碼」或「解碼」操作
- 結果會自動顯示在右側
- 點選「複製」按鈕即可儲存結果
常見錯誤
- Base64 是編碼而非加密；任何取得文字的人都能解碼，請勿用於保護機密資料。
- 解碼失敗時，請檢查是否缺少 padding、是否帶入換行字元、是否使用 URL-safe Base64 字元，或是否包含多餘的引號。
使用場景
技術原理
Base64 是 RFC 4648（S. Josefsson，2006 年 10 月）中規定的幾種二進位到文字編碼之一，與 Base16（十六進制）和 Base32 並列。'Base64' 的名稱和字母表最初定義於 Privacy-Enhanced Mail（RFC 989，1987 年），PEM 將二進位的 S/MIME 和 X.509 材料包裝在可列印的 ASCII 封套中，使其能通過 7 位元安全傳輸。同一字母表後來成為 MIME（RFC 2045）、JWT 簽章（RFC 7519）、HTML data: URI（RFC 2397）、SSH 公鑰區塊（RFC 4253 §6.6）和 Git LFS 指標檔（以 Base64 儲存 SHA-256 雜湊）的事實標準。Git 自己的 packfile 並非 Base64——它們使用 delta 編碼加 zlib 壓縮，Git 物件 ID 是 40 字元的十六進制 SHA-1 字串，而非 Base64。代價是：每 3 個輸入位元組變成 4 個輸出字元，因此編碼後的輸出正好是 4/3 的大小（33.3% 的膨脹）。對於 10 MB 的二進位資料，編碼後約為 13.3 MB。 機制如下：將輸入分成 3 位元組（24 位元）的群組；每個群組被拆成 4 個 6 位元的值；每個 6 位元值從 64 字元的字母表中選取一個字元。標準字母表為 A-Z（索引 0-25）、a-z（26-51）、0-9（52-61）、'+'（62）、'/'（63），填充字元為 '='。經典的 RFC 4648 範例：'Man'（0x4d 0x61 0x6e）打包為 24 位元值 0x4d616e；拆成 6 位元片段為 0x0d 0x16 0x0e 0x0a，對應 'TWFu'。當輸入長度不是 3 的倍數時，尾部群組在右側補零：剩餘 1 位元組 → 2 個有效 6 位元片段 + '=='（2 個填充字元）；剩餘 2 位元組 → 3 個有效片段 + '='（1 個填充）。填充字元不攜帶資訊，但它們使編碼長度成為輸入長度的確定性函數，並允許解碼器拒絕截斷的輸入。 在瀏覽器中，Base64 有兩個著名的陷阱。首先，`btoa` 和 `atob`（DOMString 變體）操作的是 Latin-1 碼單元而非位元組——傳入包含 U+00E9（é）或 U+4E2D（中）的字串會拋出 InvalidCharacterError。本頁面透過先使用 `TextEncoder().encode(str)`（始終為 UTF-8）再呼叫 `btoa` 來規避此問題，`atob` 之後再用 `TextDecoder().decode(bytes)` 解碼。UTF-8 多位元組字元會膨脹：'你' 為 3 位元組（0xe4 0xbd 0xa0）→ 4 個 base64 字元（'你好' 為 8 個 base64 字元）。其次，Base64URL（RFC 4648 §5）將 '+' 和 '/' 替換為 '-' 和 '_' 並去除填充，因為 '+' 和 '/' 在 URL 中有特殊意義，而 '=' 會終止查詢字串。JWT（RFC 7519）和 JWS（RFC 7515）正是因此要求使用 Base64URL。 Base64 是編碼而非加密——編碼後的形式沒有任何保密性，且字母表如此簡短，任何觀察者都能輕鬆讀取。將 Base64 誤認為安全機制是一個常見的 CVE 模式：CVE-2004-2761 記錄了 X.509 MD5 選擇前綴碰撞攻擊者利用碰撞的 MD5 簽章偽造憑證，而 CVE-2005-4900 等則涉及舊有的 `$1$` md5crypt 密碼雜湊被認證層重新編碼或重新雜湊的做法，該層混淆了 Base64 解碼後的位元組與新的憑證。反覆出現的模式相同：系統將編碼視為增加了一層實際上不存在的保密性，結果可被利用。真正的機密應使用 AES-GCM（RFC 5288）或 ChaCha20-Poly1305（RFC 8439）。對於先壓縮再 Base64（`gzip -b64` 所做的），注意編碼後的大小約為壓縮後的 1.37 倍，且壓縮流中任何位元組的變動都會破壞解碼——因此 Base64 是不良的完整性保護層；在編碼前對位元組進行 HMAC-SHA256 才是正確做法。
- RFC 4648（2006 年 10 月）定義了 Base64、Base32 和 Base16，使用一個標準字母表（A-Z、a-z、0-9、+、/）和 '=' 作為填充字元。MIME 變體（RFC 2045）每 76 字元插入換行以利傳輸；URL 安全變體（Base64URL，RFC 4648 §5）將 + 和 / 替換為 - 和 _ 並去除填充——JWT（RFC 7519）、JWS（RFC 7515）和 JWK（RFC 7517）使用此變體。
- 機制：3 個輸入位元組（24 位元）→ 4 個輸出字元（每個 6 位元）。膨脹率為 33.3%——每 1 MB 二進位輸入變成 1.33 MB Base64。對於 ASCII，當輸入包含 '=' 或其他被周圍協定轉義的字元時，比率可能更糟。
- 填充規則：輸入長度 mod 3 = 0 → 無填充；mod 3 = 1 → '=='（兩個填充字元，編碼 1 位元組）；mod 3 = 2 → '='（一個填充字元，編碼 2 位元組）。'=' 不攜帶資訊；它只是讓解碼器知道有多少位元組被丟棄。
- UTF-8 + btoa 陷阱：`btoa('é')` 會拋出 InvalidCharacterError，因為 btoa 將輸入視為 Latin-1 碼單元。本頁面透過先用 `TextEncoder`（UTF-8）編碼再用 btoa 來規避此問題，atob 之後再用 `TextDecoder` 解碼。沒有這個步驟，超出 U+0000..U+00FF 範圍的任何內容都會變成「0 位元組已編碼」而非錯誤。
- Base64URL 是 JWT、JWS 和 JWK（RFC 7519/7515/7517）的必要格式。它使用 '-' 和 '_' 替代 '+' 和 '/'（URL 特殊字元），並去掉 '=' 填充（會終止查詢字串）。將 JWT 標頭段傳給 Base64 解碼器而非 Base64URL 解碼器會得到亂碼；本頁面不會自動偵測——請為載荷選擇正確的變體。
- 效能：在現代筆記型電腦的 V8 上，編碼約為 400-700 MB/s（緊密迴圈執行查表和位元移位）。解碼速度相近。對於大型資料（10+ MB），瓶頸在於配置而非計算——輸出緩衝區大 33%，且 `TextEncoder/TextDecoder` 會建立副本。
- Base64 是編碼而非加密——任何人取得字串都能讀取。CVE-2004-2761（X.509 MD5 選擇前綴碰撞攻擊憑證簽章）和許多 MISC-CTF 筆記都將此誤解作為第一步。機密應使用 AES-GCM（RFC 5288）或 ChaCha20-Poly1305（RFC 8439）。對於 data: URI，注意編碼大小：10 MB 圖片變成 13.3 MB URL，超出大多數瀏覽器的 URL 長度限制和電子郵件大小限制。
- 遷移說明：Base16（十六進制）在低階協定和雜湊輸出中更受青睞，因為每個位元組對應恰好 2 個字元且長度可預測（無填充計算）。Base32 更適合人工抄寫（無相似字元）。Base64 是文字協定中二進位傳輸的通用預設，但在 HTTP/2 和 WebTransport 等支援幀的協定中，正逐漸被原始位元組取代。
範例
編碼 ASCII 文字
輸入： Hello
輸出： SGVsbG8= （5 位元組 -> 8 個字元，1 個填充字元）
輸入： Hello, World!
輸出： SGVsbG8sIFdvcmxkIQ== （13 位元組 -> 18 個字元，1 個填充字元）
輸入： Man
輸出： TWFu （3 位元組 -> 4 個字元，無填充）
'Man' 是 RFC 4648 的標準範例：位元組 0x4D 0x61 0x6E
組成 24-bit 值 0x4D616E，切成 6-bit 區塊 0x0D 0x16
0x0E 0x0A，再透過標準字母表對應到 T W F u。編碼 UTF-8 文字（中文）
輸入： 你好 （3 個 ASCII 位元組）
輸出： 5L2g5aW9 （8 個字元）
輸入： 你好世界 （4 個 CJK 字元，12 個 UTF-8 位元組）
輸出： 5L2g5aW95LiW55WM （16 個字元）
每個 CJK 字元會展開為 3 個 UTF-8 位元組（如 E4 BD A0），
Base64 輸出先膨脹約 4/3，再膨脹約 4/3 - 編碼後的字元數約
為原本的 2.67 倍。本頁會先以 TextEncoder().encode(str)
預處理，避免 btoa 對非 ASCII 輸入丟出 'InvalidCharacterError'。解碼並回送 JWT 區段
編碼後： eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
解碼後： {"alg":"HS256","typ":"JWT"}
往返：
encode('{"alg":"HS256","typ":"JWT"}') -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
decode('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') -> {"alg":"HS256","typ":"JWT"}
JWT 區段使用 Base64URL，因此頁面必須同時接受 '-' / '_'
與標準的 '+' / '/'。把 JWT 標頭丟進嚴格的 Base64 解碼器
會得到亂碼 - 請依資料內容選擇正確變體。Base64 與 Base64URL
輸入： Hello><h2>
標準： SGVsbG8+PGgyPg== （+ / = 填充；可安全用於 JSON、Email）
URL-safe: SGVsbG8-PGIyPg （- _ 無填充；可安全用於 URL 路徑與查詢）
差異：
'+' (62) -> '-' 且 '/' (63) -> '_'
URL-safe 形式完全去掉 '=' 填充
請在 JWT、JWS、JWK，以及任何透過 URL 查詢字串傳遞的權杖中
使用 Base64URL，因為 '+' / '/' 在 URL 中具有特殊意義，
而 '=' 會終結查詢字串。常見問題
Base64 是加密嗎？
不是。Base64 是一種編碼，而非加密。它只把任意位元組轉成 64 個可顯示的 ASCII 字元（A–Z、a–z、0–9、+、/），讓資料能順利通過會破壞二進位內容的系統。任何拿到編碼字串的人都能立刻解回原文，過程中沒有任何祕密。
為什麼編碼結果結尾會出現一個或兩個 = 號？
Base64 每 3 個輸入位元組會輸出 4 個字元。當輸入長度不是 3 的倍數時，編碼器會用 = 補到 4 的倍數。剩下 1 個位元組 → 補兩個 =；剩下 2 個位元組 → 補一個 =；剛好對齊 → 不需要補。有些實作會省略 = 補位，雖然合法但並非到處都能互通。
URL-safe 的 Base64 是什麼？
標準 Base64 含有 / 和 +，這兩個字元在 URL 與檔名中具有特殊意義。URL-safe Base64（RFC 4648 §5）改用 _ 與 - 取代它們，並通常省略 = 補位。JWT、URL 參數、檔名請用這個變體，其他場景則用標準 Base64。
為什麼 Base64 字串會比原始資料多出約 33%？
每 6 個位元的輸入會變成 1 個 8 位元的字元，因此編碼後長度 = ceil(input_length / 3) × 4，大約是原始長度的 4／3（約 33% 的開銷）。這就是把任意位元組以可顯示 ASCII 表示要付的代價。
可以貼哪些格式進來？
編碼時可貼純文字（內部以 UTF-8 處理）或上傳檔案。解碼時可貼帶或不帶空白的 Base64 字串——解碼器會自動移除換行。若解碼失敗，請檢查是否有雜訊字元或缺少結尾的 = 補位。
Base64 可以承載二進位檔案內容嗎？
可以，這正是它的主要用途：HTML／CSS 內嵌圖片（data: URL）、Email 附件（MIME）、HTTP 標頭中的憑證（Basic Auth）都用 Base64 把二進位塞進純文字通道。記得結果會比原始檔案大約 33%。
可以用 Base64 來隱藏敏感資料嗎？
千萬不要。Base64 不需要金鑰就能完全還原，把它當作混淆是常見錯誤，現實中已經造成多起密碼與權杖洩漏事件。敏感資料請用真正的加密或祕密管理服務。