Base64 与 Hex 编码的区别：体积、可读性与适用场景
Base64 和 Hex 都是「二进制转文本」的编码方式，让不可打印的字节流能够安全地在文本协议中传输。两者经常被混为一谈，但在字符集、体积代价和使用习惯上差别很大——选错编码轻则浪费流量，重则让数据在 URL 里被特殊字符截断。
| 对比维度 | Base64 | Hex（十六进制） |
|---|---|---|
| 字符集 | 64 个字符：A–Z、a–z、0–9、+、/，以 = 作填充符 | 16 个字符：0–9 加上 A–F，每字节固定两位数字 |
| 体积膨胀率 | 约 ×4/3（+33%）：每 3 字节变成 4 字符 | 固定 ×2（+100%）：每 1 字节变成 2 字符 |
| 人工可读性 | 低。输出看起来像随机字符串，无法直接对应到具体字节 | 高。每字节两位、按序排列，可直接对照内存转储和协议文档 |
| 长度校验 | 长度随原始字节数对 3 取模而变化，末尾可能出现 1–2 个 =，规则较绕 | 长度恒等于字节数×2，一眼即可核对数据完整性 |
| URL 与路径安全 | 标准字母表中的 + / = 在 URL 里有特殊含义，必须改用 URL-safe 变体（- 和 _）或做转义 | 仅含字母和数字，天然安全，可直接放进查询参数或文件名 |
| 典型应用 | 邮件附件（MIME）、Data URI 内嵌图片与字体、JWT 载荷、HTTP Basic 认证 | 哈希值展示（MD5/SHA）、MAC 地址、颜色代码、调试器与抓包工具的十六进制视图 |
何时选 Base64？
需要在文本通道里搬运较大的二进制数据——附件、图片内嵌、令牌载荷——时选 Base64，+33% 的膨胀远小于 hex 的翻倍。注意 Web 场景要换成 URL-safe 字母表，避免 + 和 / 被转义破坏。
何时选 Hex（十六进制）？
数据需要被人阅读、比对或手工核对——哈希指纹、密钥材料、字节级调试——时选 hex。它规则透明、没有填充歧义，几乎所有编程语言都原生支持解析。
相关在线工具
在线进制转换工具
使用我们的进制转换工具，支持2/8/10/16/32/36/52/58/62/64进制间的在线互转，输入数值后实时计算并展示各进制结果，兼容常用及扩展编码格式，适用于开发调试与数据编码查看。
在线文本与十六进制互转工具
在线文本与十六进制互转工具，基于 UTF-8 编码将任意文本（含中文、emoji）转为十六进制字节序列，字节值两位补零、空格分隔，支持双向转换与容错解析，全部本地处理。
Base64编码解码 - 在线字符串互转工具
在线Base64编码与解码工具，UTF-8 安全支持中文与 emoji，解码兼容 URL-Safe 变体（-_）与缺失填充，非法输入明确报错，全部本地处理，不上传任何数据。
常见问题
Base64 是加密算法吗？
不是。Base64 只是编码，可逆且无需密钥，任何人都可解码。保护数据请使用 AES 等真正的加密算法，Base64 只负责让密文能安全通过文本通道。
为什么哈希值都用十六进制显示？
因为哈希是固定长度的原始字节，hex 每字节恰好两位，长度整齐、便于抄录比对；用 Base64 显示虽然更短，但不同实现的对齐习惯不一，容易引起歧义。
URL 里应该用哪种编码？
优先选 hex 或 Base64 的 URL-safe 变体（用 - 和 _ 替换 + 和 /，去掉填充）。标准 Base64 直接放查询参数会被 + 变空格、/ 截断路径等规则破坏。
延伸说明
一个容易踩的坑：Base64 不是加密。它只是换一种写法表示同样的字节，任何拿到字符串的人都能瞬间还原原文，敏感数据必须先加密再编码。另外两种编码可以互相配合——比如先用 AES 加密文件，再用 Base64 把密文嵌入 JSON；调试密文时又可以用 hex 视图逐字节核对。站内提供 Base64 编解码与十六进制转换工具，全部本地运行，适合快速验证这两种编码之间的差异。