Base64 校验器
粘贴 Base64 字符串或 Data URL，即时判断是否合法。显示类型、MIME、长度、原始大小、填充状态，以及非法字符的精确位置。
校验结果
等待输入…
什么是合法的 Base64？
合法的 Base64 字符串必须满足：只含 A–Z、a–z、0–9、+、/ 共 64 个字符，以及末尾最多 2 个填充字符 =，且总长度是 4 的倍数。
Data URL 在 Base64 数据前加上 data:<MIME>;base64, 前缀，常见于 HTML img 标签的 src 或 CSS background-image。
Base64URL 将 + 改为 -、/ 改为 _，并去除末尾的 = 填充，用于 JWT、URL 参数等需要 URL 安全字符的场景。
合法字符对照
A–Z a–z 0–9 + / =（末尾）A–Z a–z 0–9 - _（无填充）data:<MIME>;base64,<Base64数据>空格 换行 ä 中文 ! @ # % …常见错误原因
含有非法字符
空格、换行、中文、! @ # 等字符均不属于 Base64 字符集，复制时常不小心带入。
长度不是 4 的倍数
缺少末尾的填充符 =，常见于手动截断或部分复制 Base64 字符串的情况。
填充符位置错误
填充符 = 只能出现在字符串末尾，且最多 2 个。中间含有 = 的字符串是无效的。
混用 Base64 与 Base64URL
将含 + / 的 Raw Base64 用于 URL 参数，或将含 - _ 的 Base64URL 用于标准解码函数，会导致解码失败。
遗漏 Data URL 前缀
向 img src 赋值时只复制了 Base64 数据，遗漏了 data:image/png;base64, 前缀，导致图片无法显示。
换行符干扰
某些工具输出的 Base64 每 76 个字符插入一个换行，用于邮件传输（RFC 2045）。直接用于 API 或 URL 时需要先去除换行。
常见问题
Base64 字符串合法的标准是什么？
合法的 Base64 字符串只能包含 A–Z、a–z、0–9、+、/，以及末尾最多 2 个填充字符 =，且总长度必须是 4 的倍数。若带 data: 前缀，还需符合 Data URL 格式。
为什么会提示 "Base64 decode failed"？
最常见原因是字符串含有非法字符（如空格、换行、中文）、长度不是 4 的倍数（缺填充符）、或填充符 = 位置不在末尾。将字符串粘贴到本工具可以精确定位问题。
Base64 和 Base64URL 有什么区别？
Base64URL 将标准 Base64 中的 + 替换为 -，/ 替换为 _，并通常省略末尾的 = 填充，使其可以安全用于 URL 参数和 JWT。如果你的字符串含有 - 或 _，就是 Base64URL 格式。
Data URL 的格式是什么？
Data URL 的格式为 data:<MIME类型>;base64,<Base64数据>，例如 data:image/png;base64,iVBORw0…。MIME 类型指明了原始数据的格式。
估算原始大小是怎么计算的？
原始字节数 = ⌊Base64长度 × 3 / 4⌋ − 填充字符数。由于 Base64 每 4 个字符对应 3 个字节，本工具可以精确还原原始大小（前提是填充正确）。
合法的 Base64 一定能正确解码吗？
格式合法是解码的前提，但不代表解码后内容就有意义。例如，一段随机字符串可能通过格式校验，但解码出的二进制数据可能无法被正确解析为文件或文本。