Base64 編碼/解碼
Base64 編碼/解碼支援文字與圖片工作流程,可對文字進行編碼與解碼,也可將圖片轉換為 Data URL 或原始 Base64,或將 Data URL / Base64 還原為圖片並在本地預覽與下載。
輸入文字
字元
0 / 500,000
選擇或拖入圖片
若瀏覽器可讀取,支援 PNG、JPEG、WebP、GIF、SVG、BMP、AVIF、TIFF、ICO、HEIC 與 HEIF。
輸出文字
輸出文字
輸入文字
字元
0 / 500,000
原始 Base64 的 MIME 類型
原始 Base64 不包含 MIME 資訊。請先選擇原始圖片類型,系統才能自動產生預覽。
貼上圖片 Data URL,或貼上原始 Base64 並選擇 MIME 類型後,即可在這裡查看預覽。
快速開始
常見使用情境
URL/JWT
優先使用 URL‑safe 變體(−/_),必要時可移除結尾「=」填充,避免連結轉義問題
郵件/MIME
需要換行時採用 MIME 76 欄(CRLF)規則;網頁傳輸一般不換行。本工具提供 76 欄換行與 LF/CRLF 切換開關
多行文字
啟用逐行編碼,每行獨立輸出
MIME/PEM
啟用 76 欄換行;需要 LF 行尾時一併啟用
Data URL
嵌入時產生 data:[mime];base64,…;解碼會自動擷取逗號之後的內容
往返校驗
編碼後立即解碼,確認還原一致
圖片上傳
保留原始位元組,且可在不重新上傳的情況下切換 Data URL 與原始 Base64 輸出
圖片 Data URL
貼上 data:image/...;base64,... 後,可自動辨識 MIME 並立即預覽圖片。
原始 Base64 圖片資料
需要明確提供原始圖片的 MIME 類型,系統才能自動預覽並下載為圖片。
編碼參數與變體
使用建議
限制與相容性
隱私與安全
常見問題
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 變體(-/_),以及文字編碼方式不一致。對比結果時,請確認雙方使用相同的文字編碼、關閉自動換行,並明確是否使用 URL‑safe 與是否保留填充。
Base64 以 6 位元表示 8 位元,約 33% 膨脹屬於方法特性
可以。表情符號、多語言字元等文字在文字模式下會以 UTF‑8 處理;如果解碼結果本身是非文字二進位內容,顯示成「亂碼」屬正常現象。