URL-safe Base64 转图片
经过 URL 或 JWT 传输的字符串，常用 - 和 _ 代替标准 Base64 的 + 和 /。本页默认按这套字母表解码。
任何格式都接受：带前缀、纯串、折行、URL 编码、URL-safe，或者已经坏掉的。
图片会显示在这里
在左侧粘贴即可，不需要点按钮。全部在你的浏览器里完成。
什么时候会用到
- 你从 JWT 的某个片段或查询参数里取出一段载荷，里面有
-或_。 - 某个 webhook 或 OAuth 流程把图片以 URL-safe 字符串的形式传给了你。
- 文件名或路径片段里的 Base64 —— 用
/会把路由弄坏。
别的 Base64 工具为什么在这里失败
两套字母表只差两个字符，所以把 URL-safe 字符串喂给标准解码器，结果要么报错，要么更糟：静默解出错字节。
只处理 - 却忘了 _ 的工具能解对一半左右的载荷 —— 这是最难察觉的一类 bug。
拿到的报错通常只有一句 Invalid character，完全没提示「可能存在另一套字母表」。
常见问题
怎么判断一段字符串是 URL-safe 还是标准 Base64？
标准 Base64 用 + 和 /；URL-safe 把它们换成 - 和 _，这样字符串才能直接放进 URL、文件名或 Cookie 而不需要转义。如果字符串里这四个字符一个都没有，两种编码完全相同，区分没有意义。
如果一段字符串里同时出现 + 和 - 呢？
那它是畸形的，或者由两个来源拼接而成。解码器会指出它选定的字母表里不该出现的那个字符，并给出精确位置。这种情况下猜测比报错更糟 —— 猜错得到的是损坏的图片，而不是一个错误提示。
URL-safe 模式是否也处理缺失的填充？
处理，这两件事互相独立。URL-safe 编码器往往也顺手去掉结尾的 =，因为它在 URL 里需要转义。两处修复都会做，并且都会列在「对你做了哪些改动」的清单里，不会瞒着你。
我打开了 URL-safe 模式，图片还是坏的。
把它关掉再对比一次。如果那段字符串里的 - 或 _ 其实属于更长的非 Base64 文本，强制按 URL-safe 解码就会读错。面板会报告它找到了多少个这类字符，通常足够区分这两种情况。