简介
这个 JWT 解码器可以直接在浏览器里查看 JSON Web Token 的内容。你可以粘贴 JWT 或 Bearer token，解码头部和载荷，检查 `iss`、`sub`、`aud`、`scope`、`iat`、`nbf`、`exp` 等常见声明，并快速判断 token 看起来是否已过期或尚未生效。全部处理都在本地完成，更适合调试场景。
使用方法
把完整 JWT 或 Bearer token 粘贴到输入框中。工具会自动移除 Bearer 前缀，按句点拆分 token，解码 Base64URL 格式的头部和载荷，并将结果格式化为可读 JSON。然后查看声明摘要和时间声明区域，必要时复制或下载解码结果用于工单、对比环境或排查日志。这个工具不会验证签名，因此适合查看内容，不适合直接信任 token。
功能特点
- •在浏览器本地解码 JWT 头部与载荷声明
- •支持原始 JWT 字符串和 Bearer token
- •分别输出可读的 Header JSON 与 Payload JSON
- •检查 `iat`、`nbf`、`exp` 等时间声明
- •快速汇总算法、签发者、主体、受众、scope 与 key ID
- •可复制或下载解码后的 JSON，方便调试流程
- •当 token 看起来已过期或尚未生效时给出提示
- •不上传服务器，也不会触发签名验证副作用
JWT 解码器能看到什么
一个 JWT 通常由三段组成，分别是头部、载荷和签名。头部一般描述算法、类型和密钥 ID 等元数据。载荷则承载 API 或应用真正关心的声明，例如 token 属于谁、面向哪个受众、何时可以使用、何时必须拒绝。
能解码不等于能验签
解码 JWT 只是把 Base64URL 编码过的 JSON 还原出来，并不代表 token 真实、可信，也不代表内容没有被篡改。签名验证需要正确的密钥材料，应该由你的应用、网关或身份系统来完成。
如何理解 exp、nbf 和 iat
iat 一般表示签发时间，nbf 表示 token 最早从什么时候开始有效，exp 表示什么时候过期。这些值通常是以秒为单位的 Unix 时间戳。排查环境问题时，要拿它们去对照真正执行鉴权的设备或服务端时钟，而不是只看本地机器时间。
常见 JWT 调试场景
当 Bearer token 在测试环境突然失效、API 返回 401 Unauthorized、多个服务之间 audience 不匹配，或者移动端刷新后似乎还在使用旧 token 时，JWT 解码器都很有帮助。它也适合先判断 token 是否结构异常，再继续排查签名密钥、会话缓存或刷新流程。
JWT 分段说明
每一段在调试时关注点不同。
| 分段 | 通常包含 | 调试提示 |
|---|---|---|
| Header | 算法、类型、key ID | 适合确认签名方案与 token 格式 |
| Payload | iss、sub、aud、exp 等声明 | 适合检查授权上下文和时间条件 |
| Signature | 签名字节 | 即使存在，也必须经过验签才能建立信任 |
常见 JWT 声明
当 token 被拒绝时，开发者最常检查这些字段。
| 声明 | 含义 | 排查提示 |
|---|---|---|
| iss | 签发者 | 确认 token 是否来自预期的身份提供方 |
| sub | 主体 | 通常表示用户、账号或服务身份 |
| aud | 受众 | 往往必须与接收 token 的 API 或资源匹配 |
| nbf | 生效时间 | 未来时间会导致 token 立刻被拒绝 |
| exp | 过期时间 | 过期 token 是 401 的常见原因 |
常见问题
这个 JWT 解码器会验证签名吗？
不会。它只负责解码 token 中可读的 JSON 部分。真正的签名验证需要正确的密钥材料，并应在其他系统中完成。
token 会上传到服务器吗？
不会。整个解码过程都在你的浏览器本地完成，不会把 token 内容发送到服务器。
为什么 token 能解码，但 API 还是失败？
因为 token 即使能正常解码，也可能在签名验证、audience、issuer、过期时间、not-before、时钟偏差或 scope 权限上不满足要求。
从请求头里复制出来的 Bearer token 能直接用吗？
可以。如果内容以 `Bearer ` 开头，工具会自动移除前缀后再解码。
如果 token 只有两段怎么办？
有些未签名或非标准 token 会省略签名段。你仍然可以查看头部和载荷，但不应把它当作已签名 JWT。