星点博客 JWT在线解析工具 - JWT Token解析、Header/Payload/Claims查看与过期判断（免费）
为什么你永远需要一个”JWT 解析器”
调试接口时最常遇到的场景：后端报 401，日志里躺着一条长长的 Token，你盯着它，脑子里只有一串 eyJhbGciOi...。它到底声明了什么算法？携带了哪些 Claims？是不是早就过期了？
星点 JWT 在线解析 / 调试器 要解决的就是这件事：把一个 JWT 粘贴进来，立刻看懂它——结构是否合法、Header 与 Payload 内容、标准 Claims、签发/过期时间、Signature 原文。全程浏览器本地完成，Token 不会上传。
不过在开始之前，有一句话必须放在最前面：解析不代表签名有效。这个工具解码并分析 Token，但不做签名验证。很多开发者把”能解析出来”误当成”签名是有效的”，这是 JWT 最常见的认知误区。
JWT 三段结构：先说清楚你在看什么
一个标准 JWT 由三段组成，用 . 连接：
Header.Payload.Signature- Header：声明算法与类型，通常形如
{"alg":"HS256","typ":"JWT"}； - Payload：承载标准 Claims 与自定义字段；
- Signature：对前两段的签名结果。
前两段是 Base64URL 编码的 JSON，所以解析器能直接解码成可读文本；Signature 是二进制签名，只能原样展示、用于后续验证。
星点的解析器在输入后立即按 . 拆分三段并校验结构，逐段展示内容与解析状态。这就是它的第一层价值：不用手动去 split(".")、不用自己 Base64URL 解码，打开即看。
Header 里有什么
Header 面板重点展示三个常见字段，也会显示自定义字段：
| 字段 | 含义 |
|---|---|
alg | 签名算法，如 HS256 / RS256 / ES256 |
typ | 类型，通常为 JWT |
kid | 密钥 ID，用于在多把密钥中定位用哪一把 |
看懂 alg 很关键：它直接告诉你，验证时该拿 Secret 还是 Public Key。
Payload 里的标准 Claims
Payload 是完整的 JSON，解析器会把它格式化展示，并把标准 Claims 单独识别出来：
| Claim | 含义 |
|---|---|
iss | 签发方（Issuer） |
sub | 主体（Subject），通常是用户 ID |
aud | 接收方（Audience） |
exp | 过期时间（Expiration Time） |
nbf | 生效时间（Not Before） |
iat | 签发时间（Issued At） |
jti | Token 唯一标识（JWT ID） |
怎么用（详细步骤）
- 打开 JWT 在线解析 / 调试器；
- 把 JWT 粘贴到输入框，或点击”示例”载入演示 Token；
- 查看顶部总体状态：结构、Header、Payload、Exp、Signature 各项结论；
- 在 Header / Payload 面板查看内容，可格式化、压缩或一键复制；
- 在 Claims 与时间区域查看签发、过期、生效时间及过期判断；
- 需要验证签名时，点击”验证签名”直接进入 JWT 签名验证 并带入 Token。
你能看到什么
| 结果区 | 说明 |
|---|---|
| 结构状态 | 三段是否完整、能否按 . 正确拆分 |
| Header | alg / typ / kid 及其他自定义字段 |
| Payload | 完整 JSON，支持格式化 / 压缩 / 复制 |
| 标准 Claims | iss / sub / aud / exp / nbf / iat / jti 单独识别 |
| 时间分析 | iat / exp / nbf 换算为本地时间与 UTC |
| 过期判断 | 未过期 / 即将过期 / 已过期 |
| Signature | 原文展示，并明确标注”未验证” |
关于时间与过期判断
iat（签发时间）、exp（过期时间）、nbf（生效时间）都是 Unix 时间戳，肉眼读不了。解析器把它们自动换算为本地时间与 UTC，并对 exp 判断三种状态：
- 未过期：当前时间早于
exp； - 即将过期：
exp距现在小于阈值（默认 10 分钟）； - 已过期：当前时间已超过
exp。
“即将过期”这个状态很实用：前端可以在 Token 快到期时提前刷新，而不是等接口报错再补救。而 nbf（生效时间）意味着”在这个时间点之前，Token 还不能用”——有些签发方会用 nbf 留出时钟偏差的缓冲。
核心概念：解析 vs 验证
这是整个 JWT 工具系列里最需要分清的一对概念。
| JWT 解析 | JWT 签名验证 | |
|---|---|---|
| 做什么 | 解码 Header / Payload，做格式与时间分析 | 用密钥重新计算签名并比对 |
| 需要密钥吗 | 不需要 | 需要 Secret（HS）或 Public Key（RS/ES） |
| 结论是什么 | ”内容能读懂、是否过期" | "签名是否有效、是否被篡改” |
| 能证明什么 | 只证明结构可读 | 证明内容未被篡改、由持有密钥方签发 |
一句话：解析成功只说明 Token 结构可读，不代表身份可信或签名有效。 任何拿到 Token 的人都能解析它——因为 Header/Payload 本质是公开可解码的 Base64URL。真正需要密码学校验的是 Signature，而这一步必须用 JWT 签名验证。
这也是为什么解析器里 Signature 面板明确标注”未验证”，并引导你去验证工具，而不是给人”已经验过了”的错觉。
HS / RS / ES 算法对比
解析器会在 Header 里看到 alg 字段，它决定 Token 用哪种签名算法。这里把三大家族说清楚：
| 家族 | 算法 | 密钥类型 | 密钥关系 | 典型用途 |
|---|---|---|---|---|
| HMAC | HS256 / HS384 / HS512 | 对称 | 签名与验证用同一个 Secret | 服务内部、单一服务场景 |
| RSA | RS256 / RS384 / RS512 | 非对称 | 私钥签名、公钥验证 | 第三方身份服务（如 Auth0、Okta） |
| ECDSA | ES256 / ES384 / ES512 | 非对称 | 私钥签名、公钥验证 | 需要更短签名、更高性能的场景 |
看到 HS256，验证时要准备 Secret；看到 RS256 或 ES256，验证时要准备公钥（PEM）。理解了 alg 的含义，你就知道下一步该拿什么去 JWT 签名验证。
为什么不建议把 alg 设成 none
有些不规范实现允许 alg: "none"（无签名）。解析器能解出内容，但这样的 Token 没有任何完整性保护，任何人都能伪造。看到 alg 为 none 或 none 之外的异常值时，应格外警惕——这属于典型的”解析能过、但完全不安全”。
常见异常提示与排查
| 现象 | 可能原因 | 处理 |
|---|---|---|
| 段数不正确 | Token 不是标准三段结构，或被截断 | 检查是否完整复制、是否多了换行/空格 |
| Header 非 JSON | Header 段不是合法 Base64URL 或内容被改 | 用 Base64URL 编码解码 单独解码核对 |
| Payload 非 JSON | 内容不是标准 JSON，或被截断/修改 | 确认 Token 是否标准 JWT，或是否被中间截断 |
| 显示”已过期” | exp 早于当前时间 | 确认服务器与客户端时间是否同步，或 Token 确实过期 |
一个完整例子
假设粘贴这样一个 Token（示意结构）：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MTYyMzkwMjIsImV4cCI6MTcxNjI0MjYyMn0.签名部分解析器会告诉你：
- 结构：三段完整；
- Header：
alg=HS256、typ=JWT； - Payload：
sub=1234567890、name=John； iat/exp换算后的本地时间，并给出”未过期 / 即将过期 / 已过期”结论；- Signature：展示原文，标注”未验证”。
这个例子也直观展示了”解析”与”验证”的区别：解析器能读出 sub=1234567890，但它不会、也不能告诉你这个 Signature 是否真的是用合法 Secret 签出来的。
别混淆：JWT / JWS / JWE / JWK
接触 JWT 时，经常碰到几个长得像的缩写，混在一起很容易晕：
| 缩写 | 全称 | 是什么 |
|---|---|---|
| JWT | JSON Web Token | 承载”声明”的 Token 格式 |
| JWS | JSON Web Signature | 带签名的 JWT，即最常见的”三段式”结构 |
| JWE | JSON Web Encryption | 加密的 JWT，内容被密文包裹，与签名是两回事 |
| JWK / JWKS | JSON Web Key (Set) | 用于存放公钥的 JSON 格式，常见于身份服务 |
平时说的”解析 JWT”，绝大多数指的是解析 JWS（带签名、可读明文前两段）的那种 Token。解析器能解出 Header/Payload，正是因为 JWS 的前两段是 Base64URL 编码的明文 JSON，而非加密内容。如果拿到的 Token 前两段解出来是一堆无法读懂的二进制，那它可能是 JWE（加密 Token），需要先解密才能看到内容——这不在”解析”能力范围内。
手动解码前两段，理解解析器在做什么
解析器做的事其实很透明，你也可以手动复现，帮助理解原理：
- 把 Token 按
.切成三段； - 取前两段，把
-换回+、_换回/，补上=填充； - 做 Base64 解码，按 UTF-8 还原文本；
- 得到的字符串就是 Header 和 Payload 的 JSON。
不想手动做，就用 JWT Base64URL 编码解码 的 JWT 专用模式一键提取解码。而解析器在这之上还多做了结构校验、Claims 识别与时间换算，一步到位。
什么时候用解析，什么时候用验证
两个工具边界清晰，按这个判断即可：
| 你的问题 | 用哪个工具 |
|---|---|
| 想看 Token 内容、Claims、过期时间 | JWT 在线解析 |
| 想知道签名是否有效、是否被篡改 | JWT 签名验证 |
| 要自己造一个 Token | JWT 生成器 |
| 要把 Token 拼成请求头调接口 | JWT → Authorization Header |
典型的排查顺序：先解析看结构，再验证判真伪，最后结合 exp / iss / aud 下结论。
常见问题（FAQ）
解析 JWT 会验证签名吗？
不会。解析只解码 Header、Payload 并做格式与时间分析，不验证签名。解析成功只说明 Token 结构可读，并不代表身份可信或签名有效。为什么有的 Token 解析后 Payload 不是 JSON？
标准 JWT 的 Payload 应为 JSON。若提示"Payload 不是有效 JSON"，说明该 Token 可能不是标准 JWT，或内容被截断、被修改。Signature 能解密出什么？
Signature 不可解密，它是对 Header.Payload 的签名结果，只能用于验证。本工具仅展示其原文，不伪造、不验证。我的 Token 会被上传吗？
不会。所有解析都在浏览器本地完成，不产生任何网络请求，请放心使用。"即将过期"是怎么判断的？
以当前时间为基准，若 exp 距现在小于阈值（默认 10 分钟）即标记为"即将过期"，已小于当前时间则标记为"已过期"。解析完想验证签名怎么办？
点击"验证签名"直接进入 [JWT 签名验证](https://www.xingdian.net/app/jwt/verify/)，Token 会一并带入。能自己造一个 Token 来解析吗？
可以，用 [JWT 生成器](https://www.xingdian.net/app/jwt/generate/) 生成后回解析器核对；快速测试用 [JWT 测试 Token 生成器](https://www.xingdian.net/app/jwt/testtoken/)。Header 里的 kid 是干什么的？
`kid`（密钥 ID）用于在签发方有多把密钥时，告诉验证方该用哪一把公钥来验签，常见于使用 JWKS 的身份服务。为什么有的 Token 解析出来 Payload 是加密的一堆乱码？
那可能不是 JWS（带签名）而是 JWE（加密）Token。JWE 的内容是密文，需先解密才能读到明文，超出了"解析"能力范围。解析出来的时间和我本地时间对不上？
时间以 UTC 展示，同时换算成本地时间。若仍觉得对不上，检查你的设备时区与系统时钟是否准确，或 Token 的 `iat`/`exp` 本身填错。任何算法的 Token 都能解析吗？
能。解析不涉及算法，只要结构是三段 Base64URL，都能解码出 Header 与 Payload；`alg` 字段只影响后面的签名验证阶段。nbf 和 exp 有什么区别？
`exp`（过期时间）表示"此后不可用"，`nbf`（生效时间）表示"此前不可用"。二者配合可限定 Token 的有效时间窗口。支持移动端使用吗？
支持。解析器做了移动端适配，手机、平板、电脑都能用，粘贴 Token 即可解析。总结
JWT 解析的核心是”即时看懂”：粘贴即得 Header/Payload/Claims/时间/过期判断，省去手动解码。但务必记住解析与验证的边界——解析器只负责把 Token 读懂，判断它是否可信要靠 JWT 签名验证。
立即体验：访问 JWT 在线解析 / 调试器
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！