JWT 在线解析怎么用
- 把令牌粘贴到输入框——就是那串以
eyJ开头的长文本。直接从浏览器开发者工具、Postman 或日志里复制的Authorization: Bearer …请求头、令牌两边的引号、中间的换行都会被自动清理。 - 查看解码后的头部和载荷（格式化的 JSON）、最上面的有效期状态，以及各个标准声明：时间按你所在的时区显示，并注明是多久以前或多久以后。
- 要验证签名，填入密钥：HS256、HS384、HS512 填共享密钥；RS、PS、ES、EdDSA 令牌填公钥，可以是 PEM、JWK 或整个 JWKS。结果会显示签名有效或签名无效。
JWT 里有什么
JSON Web Token（RFC 7519）是用点连接的三段 base64url 文本：header.payload.signature。头部和载荷都是 JSON 对象，只是编码过、并没有加密——所以它们总是以 eyJ 开头，这正是 {" 的编码。头部写明签名算法（alg）；载荷放的是声明（claims），即关于用户或会话的信息。签名是对前两段原文计算出来的，任何一段改动一个字符，签名都会失效。
| 声明 | 名称 | 含义 |
|---|---|---|
iss | 签发者 | 谁创建并签名了令牌，通常是登录服务的网址 |
sub | 主题 | 令牌是关于谁的，通常是用户 ID |
aud | 受众 | 应该接受它的服务；发给某个接口的令牌，别的接口必须拒绝 |
exp | 过期时间 | 超过这个时刻，令牌必须被拒绝 |
nbf | 生效时间 | 早于这个时刻，令牌必须被拒绝 |
iat | 签发时间 | 令牌创建的时间 |
jti | JWT ID | 唯一编号，服务器可以据此拒绝重复使用的令牌 |
这三个时间都是 NumericDate：自 1970 年 1 月 1 日（UTC）起的秒数，和 Unix 时间戳相同。13 位的数字是毫秒——这是常见的 bug，解析器会指出来。注意北京时间是 UTC+8：服务端日志按 UTC 记录、前端按本地时间显示时，相差 8 小时是正常的。服务器通常会允许一两分钟的时钟误差，这里显示的状态不留任何余量。
计算示例
JSON Web Signature 标准 RFC 7515 的第一个示例（附录 A.1）签名了这个令牌：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
它的头部解码为 { "typ": "JWT", "alg": "HS256" }——一个 HMAC SHA-256 令牌；载荷解码为 { "iss": "joe", "exp": 1300819380, "http://example.com/is_root": true }。所以签发者是“joe”，有一个私有声明（http://example.com/is_root），而 exp 1300819380 是 2011-03-22 18:43:00 UTC，即北京时间 2011 年 3 月 23 日 02:43。2026 年 10 月解析时，状态显示为已于 16 年前过期。要验证签名，把 RFC 给出的密钥以 JWK 形式粘贴进去：
{"kty":"oct","k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"}
签名就会显示为有效。把载荷改动一个字母，签名就会变成无效。
输入框里默认的令牌是 jwt.io 上广为人知的示例，密钥是 your-256-bit-secret。这个密钥只有 19 字节，比 RFC 7518 对 HS256 要求的 32 字节短，验证后解析器会给出提示。
验证签名
- HS256、HS384、HS512用同一个共享密钥签名和验证。直接输入密钥原文；如果密钥是 Base64 编码保存的，请以
oct类型的 JWK 粘贴。Java 的 jjwt、Node.js 的 jsonwebtoken、Go 的 golang-jwt 默认都按原文字节使用密钥。 - RS256、PS256（RSA）和 ES256（椭圆曲线 P-256；ES384、ES512 对应 P-384、P-521）用私钥签名、用对应的公钥验证。登录服务通常在
/.well-known/openid-configuration列出的jwks_uri上公开 JWKS 公钥集；把那段 JSON 粘贴进来，解析器会自动选出kid与令牌一致的公钥。 - 验证使用浏览器内置的 Web Crypto，也就是保护 HTTPS 的那套代码。密钥只用于验证：不会签名、保存或发送任何东西。
安全提示
- 解码不等于验证。任何人都能读出 JWT，也能自己写一个带任意声明的 JWT。只有服务器验证了签名、
exp、iss和aud之后，令牌才可信。 - 拒绝 alg 为“none”的令牌。它表示没有签名，接受它就等于让攻击者冒充任何身份（RFC 8725，JWT 最佳实践）。
- 固定算法。如果服务器用自己的 RSA 公钥当作“密钥”去验证 HS256 令牌，就会被伪造的令牌骗过，这就是算法混淆攻击。解析器会拒绝这种组合。
- 不要把正在使用的生产环境令牌粘贴到网站上——包括本站。本页虽然在本地解析、不发送任何内容，但有效的令牌在过期前就相当于密码。尽量使用已过期或测试环境的令牌，也永远不要粘贴私钥：验证只需要公钥。
- 载荷里不要放机密。手机号、身份证号这类个人信息放进载荷，任何拿到令牌的人都能读到。如果声明本身必须保密，请使用五段式的加密 JWT（JWE）；解析器能识别它并显示其头部。
需要把令牌里的 ID 和数据整理成表格时，可以用 JSON 转 CSV；载荷 JSON 很长时，用 JSON 格式化查看更方便。
常见问题
把 JWT 粘贴到这里安全吗？
令牌由你浏览器里的 JavaScript 解析和验证，不会发送到服务器，页面也不保存它。不过有效的令牌就像临时密码，在任何网站上最稳妥的做法都是只粘贴已过期或测试用的令牌；如果在不信任的地方粘贴过正在使用的令牌，请退出登录（部分系统会因此吊销令牌）。
没有密钥能解析 JWT 吗？
能。头部和载荷只是 base64url 编码，不需要任何密钥就能读出。密钥或公钥只在验证签名时需要，用来证明令牌是真的、没有被改动过。
为什么显示“签名无效”？
要么令牌在签名后被修改过，要么用的不是签名时的那个密钥：别的环境的密钥、多了或少了一个字符、密钥轮换后用错了公钥，或者密钥本应先做 Base64 解码（这时请以 oct 类型的 JWK 粘贴）。
JWT、JWS 和 JWE 有什么区别？
JWS（RFC 7515）是三段式的签名数据，JWE（RFC 7516）是五段式的加密数据。JWT（RFC 7519）是一组声明，装在两者之一里——几乎总是 JWS，所以平常说的“JWT”一般指签名令牌。
怎么看令牌什么时候过期？
看过期时间（exp）：解析器把它显示成你所在时区的日期，并注明“3小时后”或“2天前”。没有 exp 声明的令牌本身永远不会过期，对访问令牌来说这是有风险的。
最后更新：2026年10月16日