Base64 編碼/解碼
Base64 編碼/解碼
Base64 編碼/解碼: 支援文字與二進位資料的 Base64 編碼與解碼,提供 URL-safe 及 MIME 格式選項。支援 Data URL 解析、逐行編碼及自動格式辨識,適用於 API 呼叫、郵件附件及資料嵌入。
快速開始
常見使用情境
URL/JWT
優先使用 URL‑safe 變體(−/_),必要時可移除結尾「=」填充,避免連結轉義問題
郵件/MIME
需要換行時採用 MIME 76 欄(CRLF)規則;網頁傳輸一般不換行。本工具提供 76 欄換行與 LF/CRLF 切換開關
多行文字
啟用逐行編碼,每行獨立輸出
MIME/PEM
啟用 76 欄換行;需要 LF 行尾時一併啟用
Data URL
嵌入時產生 data:[mime];base64,…;解碼會自動擷取逗號之後的內容
往返校驗
編碼後立即解碼,確認還原一致
Image upload
Keep the original bytes and switch between Data URL and raw Base64 output without re-uploading
Image Data URL
Paste data:image/...;base64,... to auto-detect MIME and rebuild a previewable image
Raw Base64 image data
Supply the original image MIME explicitly before reconstructing or downloading
補充場景
Base64 轉換、文字轉 Base64、圖片轉 Base64 也可在同一流程中完成,便於在複製、匯出或交付前快速核對結果。
編碼參數與變體
使用建議
限制與相容性
會話管理
常見問題
Base64 是一種將任意二進位資料以可列印文字表示的編碼方案。它源於 1990 年代的電子郵件 MIME 標準(RFC 1521/2045),之後由 RFC 4648 統一規範。目的不是「加密」,而是在以文字為主的通道上可靠攜帶位元資料。 工作原理:每 3 個位元組(24 位)拆成 4 個 6 位區塊,映射到 A–Z、a–z、0–9、+、/ 共 64 個字元;若來源長度不是 3 的倍數,使用「=」填充對齊。體積通常增加約 33%。 變體與選擇:RFC 4648 定義了 URL‑safe 變體,用「-」「_」取代「+」「/」,結尾「=」可省略。URL、Cookie、JWT 等情境建議使用 URL‑safe;對接傳統/MIME 工具鏈時使用標準 Base64(保留 +/ 與 =)。本工具預設輸出 URL‑safe,解碼自動相容兩種變體。 範例:??? → 標準為 Pz8/,URL‑safe 為 Pz8_;~~~ → 標準為 fn5+,URL‑safe 為 fn5‑。 與 Data URL:需要將資料內嵌到文字(如 HTML/CSS)時,常寫作 data:[mime];base64,…;解碼時只需擷取逗號後的部分(本工具會自動處理)。 里程碑(簡史):1993 RFC 1521(MIME v1,Ned Freed & Nathaniel Borenstein)→ 1996 RFC 2045(MIME 更新,取代 1521)→ 2003 RFC 3548(Simon Josefsson,抽象 Base16/32/64)→ 2006 RFC 4648(Simon Josefsson,統一並明確 Base64URL,廢止 3548)。另:1993 RFC 1421(PEM,J. Linn)使用 Radix‑64(與 Base64 同宗)以便郵件中攜帶二進位資料。 安全提示:Base64 是可逆格式化,並不提供機密性或完整性;機密內容請先加密再編碼。
不是。任何人皆可解碼;需保密請先加密
請確認內容僅包含 A–Z、a–z、0–9、+、/、=,且長度符合規則
差異常見於換行處理、是否保留 '=' 填充、URL‑safe 變體(−/_)與實作細節。建議統一 UTF‑8、停用自動換行,並事先決定是否採用 URL‑safe 與是否保留填充
Base64 以 6 位元表示 8 位元,約 33% 膨脹屬於方法特性
使用 UTF‑8 可支援。非文字二進位解碼後可能看似亂碼