开发者常用的在线编码与解码工具
在浏览器中完成 Base64、URL、HTML 实体、证书、二维码等编码与解码。
选择一个工具
编码解决的是「怎么表示」，从来不是「怎么保密」。
这里的八个工具都在做同一类事：把一个值换一种表示方式——文本转 Base64、字符转百分号转义或 HTML 实体、字节转 Data URL 或二维码图像、压缩字节还原成可读文本。其中三个更偏向「查看」而非「转换」。这一类里没有任何操作能带来机密性，因为拿到输出的人都能把它还原回去。选工具的依据是「谁来解析这个值」，而不是哪种输出看起来更整齐。
三个转义工具，彼此不能互换
URL 编码解码、HTML 实体编码解码和 Base64 编码解码经常被混用，因为它们都把可读文本变成不那么可读的样子。判断依据是目的地：URL 组件用百分号编码，要落进 HTML 的文本用实体，需要穿过纯文本通道的任意字节用 Base64。
用错上下文的编码，往往能通过评审却在生产环境出问题。HTML 属性里做了百分号编码的 & 对 HTML 解析器来说仍然是个未转义的 & ；而查询串里的实体只是几个服务端永远不会解码的多余字符。当一个值要穿过两层边界时，就按它经过的顺序，每层各编码一次。
文本 Base64、图片 Base64，以及解决相反问题的 Gzip
Base64 编码解码面向字符串：一个请求头的值、一个令牌、一段必须塞进只接受文本的字段里的内容。它提供 Base64URL 字母表，凡是接收方是 JWT 或 URL 的场景都应该选它。Base64 图片编解码面向字节，会报告识别出的媒体类型，并输出可以直接粘进 CSS 或 HTML 的 Data URL。
两者都会让载荷膨胀约三分之一。Data URL 适合小的内联素材和测试夹具，不适合真正的图片，因为它无法被单独缓存。Gzip 压缩解压解决的是反方向的问题，同时也是你查看「已压缩响应体」时该用的工具。
告诉你一个值里面本来装着什么的三个工具
证书解析、JWT 解码与验签、二维码生成与识别回答的是同一类问题。证书解析把 PEM、DER、PFX 或 PKCS#12 展开成主题、有效期、SAN 列表和证书链；JWT 工具把头部与载荷拆开；二维码识别支持上传、粘贴和摄像头三种输入。
解码 JWT 和验证 JWT 被有意拆成了两件事。任何拿到令牌的人都能读出其中的声明，因为那几段是 Base64URL 而不是加密，所以解码结果只说明签发方声称了什么。信不信它，取决于用正确的密钥做签名校验，以及顺手看一眼 exp 和 aud。
在采信结果之前
- 字母表要与接收方对齐：令牌和 URL 用不带填充的 Base64URL，其余场景用标准 Base64。
- 每穿过一层上下文边界就编码一次，顺序与值实际经过的顺序一致。
- 在相信解码出的任何声明之前先验签，并顺便读一下 exp 和 aud。
- 看证书时别只看主题，要看有效期和 SAN 列表。绝大多数证书故障不是叶证书过期，就是 SAN 里少了一个域名。
- 把粘贴进来的一切都视为可见内容。编码按定义就是可逆的，真正的密钥请在进入任何工具（包括本站）之前先脱敏。
常见问题
Base64 算加密吗？
不算。Base64 只是用受限字符集表示字节，还原它根本不需要密钥。把 API Key 编码一遍不会带来任何保护。需要机密性时，传输上用 TLS，存储上用密钥管理系统。
查询串参数该用哪个工具？
用 URL 编码解码，并且只对单个组件编码，不要对整条 URL 编码。对完整 URI 编码会把构成结构的斜杠和问号一起转义掉，这正是工具区分「组件编码」和「整体编码」的原因。
同一个 JWT 为什么在别处能验通、在这里却失败？
几乎总是算法或密钥的问题。HS256 用的是共享密钥，RS256 用的是公钥；而且有的系统把 HMAC 密钥先做 Base64 解码，有的直接用字符串的原始字节。怀疑令牌之前，先核对头部的 alg 和你粘进去的密钥。
证书、令牌和图片会离开我的浏览器吗？
不会。这一类工具都在标签页内本地运行，不传输也不跨访问保存。但这只是关于网络的陈述，不是关于屏幕的：私钥或一个仍然有效的会话令牌，对浏览器里运行的一切依然是暴露的。