Base64 编码/解码
Base64 编码/解码
Base64 编码/解码支持文本与图片两种处理模式,可对 UTF-8 文本进行编码与解码,也可上传图片生成 Data URL 或原始 Base64,并在本地重建预览与下载。
快速开始
常见使用场景
URL/JWT
优先使用 URL‑safe 变体(−/_),必要时可移除结尾“=”填充,避免链接转义问题
邮件/MIME
需要换行时采用 MIME 76 列(CRLF)规则;网页传输一般不换行。本工具提供 76 列换行与 LF/CRLF 切换开关
多行文本
开启“逐行编码”,每行独立输出 Base64,便于逐条处理
MIME/PEM
开启“按 MIME 76 列换行(CRLF)”;若需 LF 行尾,同时开启“换行使用 LF(\n)”
Data URL
嵌入时生成 data:[mime];base64,…;解码会自动截取逗号后的内容
往返校验
编码后立即解码,确认还原一致
图片上传
保持原始字节不变,可在 Data URL 与原始 Base64 输出之间来回切换,无需重新上传
图片 Data URL
粘贴 data:image/...;base64,... 可自动识别 MIME 并重建可预览图片
原始 Base64 图片数据
重建或下载前,需要显式提供原始图片 MIME 类型
补充场景
Base64 转换、文本转 Base64、图片转 Base64 也可在同一流程中完成,便于在复制、导出或交付前快速核对结果。
编码参数与变体
使用建议
限制与兼容性
隐私与安全
常见问题
Base64 是一种把任意二进制数据安全表示为文本字符的编码方案。它最早用于电子邮件的 MIME 标准(1990 年代,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 可支持。非文本二进制解码后可能显示为“乱码”