永不上传你 Token 的隐私安全 JWT 调试器

晚上 11 点你在调试 OAuth 流程，从浏览器 Network 面板里抓了一个 JWT 想确认某个 claim 是否设对了，顺手粘贴到 Google 第一条结果的 JWT 解码器里——下一秒你才想起，你刚刚把一个由你生产环境身份提供商签发的、可用的 access token 交给了一个第三方网站——这个 token 有能力登录你客户的账号、调用你内部 API、读取 scope 内的任何数据。

公网上几乎每一个流行的 JWT 解码器——jwt.io、jwtdecoder.net、以及数十个克隆站——在把内容显示给你之前，都会先把粘贴的 token POST 到它们自己的服务器。它们的隐私页面会说"我们不存储"，这或许是真的，但 token 仍然横跨了开放互联网、命中了第三方 HTTPS 端点，并在它们的 HTTP 访问日志里保留了某段时间。对生产环境的 token 而言，这是一起值得披露的安全事件。

本文会讲清楚 JWT 究竟是怎么工作的、"解码"一个 JWT 到底在做什么，以及如何用完全在浏览器内运行的 Ai2Done JWT 解码器 安全地调试它们。

TL;DR

• 一个 JWT 就是三段用点分隔的 base64 字符串——头部、载荷、签名。
• "解码"一个 JWT 只是对前两段做 base64 解码——这不是签名验证。
• 大多数在线 JWT 解码器会把 token 发到服务器。哪怕它们说不记日志，token 也已经离开你的机器、进入了某处的访问日志。
• Ai2Done JWT 解码器 完全在浏览器里运行——你的 token 不会离开当前标签页。
• 对带真实权限的生产 token，这是唯一安全的模式。把一次"把生产 JWT 粘贴到第三方工具"当作把密码递了出去。

为什么这件事比看起来更难

JWT（JSON Web Token，RFC 7519）的结构其实非常简单：

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3NTAwMDAwMDB9.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

三段用 . 分隔：

1. 头部（eyJhbGciOiJIUzI1NiJ9）—— base64 编码的 JSON {"alg":"HS256"}，描述签名算法。
2. 载荷（eyJzdWIi...）—— base64 编码的 JSON，包含真正的 claim（sub、exp、自定义字段）。
3. 签名（dBjftJeZ...）—— 对 header.payload 做 HMAC 或 RSA/ECDSA，用来校验完整性。

"解码"一个 JWT 就是把第 1、2 段 base64 解码、读出里面的 JSON。这件事不需要密钥、不需要联网、不需要服务器。一段 5 行的 JavaScript 函数就够了。然而 99% 的在线 JWT 解码器仍然坚持把你的 token 绕到它们的后端走一圈——意味着 token 最终会进入：

• 它们服务器的 HTTPS 终止日志
• 它们反向代理的访问日志
• 可能进入应用日志（取决于具体实现）
• 它们 CDN 的边缘日志（Cloudflare、Fastly 等）
• 页面加载的合作伙伴广告、错误追踪服务、统计分析服务对应的日志

哪怕运营方意图善良，你的生产 token 此刻已经被持久化在 2-3 家不同公司的 4-6 份日志里，保留期从 7 天到"永久"不等。攻击者一旦攻破其中任何一个目标，就拿到了一个可用的、能访问你客户资源的 bearer token。

这不是被害妄想，这是处理生产凭据时的标准威胁建模。

方法一：Ai2Done JWT 解码器（浏览器端，正确做法）

**Ai2Done JWT 解码器**是约 200 行纯 JavaScript，运行在你的浏览器标签页里。粘贴 token、看清内容、关闭标签页——这个 token 就永远消失。流程：

1. 在任何浏览器中打开 /tools/jwt_decoder。
2. 把你的 JWT 粘贴到输入框。
3. 解码后的头部与载荷会立即以语法高亮的 JSON 面板显示。
4. 可选：粘贴你的签名密钥（HS256）或公钥（RS256），本地完成签名验证。整个验证过程也是 100% 客户端。

开箱即得的能力：

• 头部解码：显示算法与密钥 ID
• 载荷解码：所有自定义 claim 和标准 claim（iss、sub、aud、exp、nbf、iat、jti）
• 人类可读的时间戳——exp: 1750000000 同时显示为"还有 47 分钟"，你可以一眼看出 token 是否已过期或即将过期
• Claim 校验提示——exp 已过则字段标红；不确定 aud 是否对就粘贴期望值即时对比
• 签名验证——粘 HS256 密钥、RS256 公钥（PEM）或 JWKS URI，工具告诉你签名是否有效。底层用 Web Crypto API，全程在浏览器里完成。

整个 bundle 约 40 KB，在任何设备上不到 1 秒加载完成；缓存后离线可用；首次加载之后零网络调用。

方法二：终端里的 5 行脚本

如果你已经在终端里工作，最简单的 JWT 解码器就是一行 bash：

echo "YOUR_JWT_HERE" | cut -d. -f2 | base64 -d 2>/dev/null | jq .

这段命令：

1. 用 cut 把 JWT 切分，取第二段（载荷）
2. base64 解码（2>/dev/null 屏蔽 padding 警告）
3. 用 jq 美化输出

要看头部，把 f2 改成 f1。要做签名验证，请用真正的库——python -c "import jwt; print(jwt.decode(...))" 或你的语言里的等价物。不要试图在 bash 里手写 HMAC-SHA256 验证。

这是"我已经 SSH 到服务器了，现在需要查一个 token"的最优解。已经在浏览器里就别折腾这个。

方法三：原生 macOS / Windows 应用

如果你讨厌浏览器工具，市面上也有几款纯离线的 JWT 解码器：

• macOS：JWT Inspector（免费，App Store）
• Windows：IDESoft 的 JWT Decoder（免费，MS Store）
• 跨平台：VS Code 扩展 "JWT Debugger"（在编辑器里直接用）

它们都完全在设备上运行，没有任何网络请求。挑一个适合你工作流的即可。

我们是怎么做的（技术细节）

Ai2Done JWT 解码器 刻意做得极简：

• 零框架——纯原生 JS，约 200 行，约 40 KB（gzip）。3G 网络也能秒载。
• 零分析、零埋点——按设计，我们不知道有多少人用它。路由级的页面访问会被记录（/tools/jwt_decoder 收到 X 次访问），但绝不携带任何由 token 派生的信息。
• 默认 base64url 安全——JWT 使用 base64 的 URL 安全变体（用 -_ 替代 +/），两种我们都处理。
• 签名验证走 Web Crypto——crypto.subtle.verify() 原生支持 HMAC-SHA256/384/512 和 RS256/384/512；ES256/384（ECDSA）在现代浏览器也能跑；PS256（RSA-PSS）需要一段小型 JS shim，因为某些老浏览器没有。
• JWKS 支持——粘一个 JWKS URI（如 https://accounts.google.com/.well-known/jwks.json），工具会拉取 JWK 集合、找到匹配 token kid 的密钥、完成签名验证。这一次请求是你的浏览器直接对接 IdP，不会经过我们。

一个刻意的设计决策值得点名：我们不提供"签发 JWT"功能。整个工具是只读的。签发需要私钥/密钥，而我们不希望培养用户"把 HMAC 密钥或 RSA 私钥粘到网页里"的习惯。签发请在你自己的应用代码里用正经库完成；这个工具的角色是验证你拿到的东西。

常见问题

Q：解码 JWT 这件事本身有安全风险吗？ A：没有——base64 解码头部和载荷，只会暴露签发方主动放进去的内容。JWT 规范说得很清楚：载荷是 base64 编码、不是加密。任何人持有 token 就能读到里面。真正的风险是让 token 本身泄漏——它是一个 bearer 凭据，谁拿到谁就能用。

Q：token 的 exp 已经在过去，但 API 仍然接受。为什么？ A：可能的原因：(1) 服务器实际校验的是 nbf 或 iat，忽略了 exp；(2) 服务器有时钟漂移容忍，允许 N 分钟内过期的 token；(3) 这其实是 refresh token，不像 access token 那样快过期；(4) API 真的有 bug。查阅你 IdP 的校验策略。

Q：没有 IdP 的公钥，怎么验证签名？ A：你做不到——这就是签名的意义。签名证明 token 是被持有密钥的人签发的。如果你既没有公钥（RS256）也没有共享密钥（HS256），你就无法校验完整性。解码器会告诉你"未验证——请提供密钥"。这是正确行为。

Q：为什么工具把一些 claim 标记为标准、其它的标记为自定义？ A：RFC 7519 保留了一组标准 claim 名：iss、sub、aud、exp、nbf、iat、jti。其它的都是自定义（如 name、email、roles、应用专属 claim）。解码器会按 RFC 定义的语义高亮标准 claim，并把其余字段当作任意结构的 JSON。

Q：能解码加密的 JWE token 吗？ A：没有解密密钥则不能。JWE（JSON Web Encryption，RFC 7516）是真的加密了，没密钥时载荷不可读。工具会根据头部的 enc 字段识别 JWE 与 JWS，并告诉你"无密钥无法解码加密 token"——并且我们不提供密钥粘贴框，这种敏感操作应该发生在你自己的代码里。

Q：这个工具离线能用吗？ A：能。首次访问后工具进入浏览器的 HTTP 缓存，离线也能继续工作——在调试空气墙环境里的 token、或网络中断时尤为有用。

现在就试

不必把 JWT 递给陌生人就能调试：

打开 JWT 解码器 →

粘贴、看清、关闭。你的 token 不会离开当前标签页。

相关阅读

• JSON、YAML、XML、CSV——一套工具的来回转换——更细致地查看 JWT 内的 JSON
• Cron 表达式解析器——给非运维的同学——另一个完全在浏览器内运行的开发者工具
• WASM 端处理：为什么我们让一切在你的浏览器内完成
• 浏览全部开发者工具

最后更新于 2026-06-14。JWT 解码器 100% 在你的浏览器标签页内运行——你的 token 永远不会离开设备。我们没有 token 内容的服务器日志、没有 token 内容的统计分析、关闭标签页后无任何方式找回解码后的 token。