文本与文件互转 Base64：URL-safe 字符表、自动补全填充、识别 data URI 里的真实文件类型，全部在浏览器里完成。
编码结果会显示在这里…这个页面有四个方向：文本转 Base64、Base64 转文本、文件转 Base64、Base64 转文件。前两个处理日常粘贴，后两个对应两件很具体的事——把一个小图标塞进 CSS，以及别人丢给你一长串 `data:image/png;base64,…` 时把原图拿回来。
解码这一侧刻意做得宽容：换行、空格、缺失的 `=`、URL-safe 的 `-` 和 `_`、连 `data:` 前缀都会自动处理，并把你粘贴的内容里被修正的地方逐条标出来。因为你手里的 Base64 很少是干净的——从邮件里复制会带上每 76 字符一个的换行，从 JWT 里取出来的则是没有填充的 URL-safe 变体。
Base64 做的事只有一件：把每 3 个字节（24 bit）切成 4 段 6 bit，每段对应 64 个可打印字符里的一个。所以「加密」和「解密」都不需要密钥，任何人拿到都能还原。它存在的理由是历史包袱——早年的邮件协议只保证 7 位字节安全传得过去，二进制附件必须转成纯文本，这套编码就一直用到了今天的 PEM 证书、JWT 和 data URI。
代价是体积放大三分之一：3 字节变 4 字符。把密码、密钥用 Base64「藏」进配置文件，效果等于明文——这一点经常被误解，也经常因此出事。真要保护内容，用 AES；真要证明内容没被改，用 HMAC。
浏览器原生的 `atob` 相当严格，少一个 `=` 就抛异常。实际遇到的失败几乎都能归到下面几类，这里的解码器对每一类都做了处理：
Base64 只搬运字节，不定义字符集。同一句「你好」，按 UTF-8 编码是 6 个字节，按 GBK 是 4 个，按 Latin-1 根本表示不了。解码端如果猜错字符集，看到的就是乱码。
本页的文本解码严格按 UTF-8，并且是「不容错」的：字节序列不合法时直接报错，而不是把坏字节替换成问号输出一段看似正常的文字。这样至少你知道问题出在编码上，而不是拿到一份看着像样、实际已经损坏的数据。
data URI 的收益是少一次请求，成本是体积涨三分之一、无法单独缓存、并且会跟着 CSS 一起下载、一起阻塞首屏渲染。HTTP/2 之后请求数早已不是瓶颈，这笔交易越来越不划算。
经验值：1–2 KB 的图标、字体子集值得内联；几十 KB 的照片内联通常更慢。页面在输出体积旁边直接标了增长比例，超过 1 MB 会给出提示——那个量级应该用文件引用，而不是塞进 HTML。
data URI 的头部写着 `image/png`，但那行字是手写的，可能写错，也可能干脆没有（只有一串裸 Base64）。所以判断顺序是先看字节、再看声明：PNG 的开头是 `89 50 4E 47`，JPEG 是 `FF D8 FF`，PDF 是 `%PDF`，ZIP 是 `50 4B`。头部声明只在字节识别不出来时兜底。
能识别的类型会直接给出对应扩展名下载，图片还会当场预览一张。实在判断不出来的，落到 `application/octet-stream`，存成 `.bin`——这比猜错扩展名、让系统用错误的程序打开要诚实。