JWT 解析工具

在输入框粘贴完整的 JWT 字符串（以 eyJhbGciOi 开头的那一整串）。
工具自动解码 Header 与 Payload，并以 JSON 形式展示。
在 Claims 摘要面板查看 exp / iat / iss / aud / sub，时间会转为可读格式。
如需验证签名，输入对称密钥（HS256/HS512）或 PEM 公钥（RS256），点击验证。

帮助与说明

常见问题

JWT 是加密的吗？展开

不是（绝大多数情况下）。标准的 JWS Token 只是做了 Base64URL 编码和签名，任何人都能读出 Payload 的内容，包括本工具。签名验证证明的是完整性和来源，不是机密性。如果需要加密，应该使用 JWE（加密 Token），它有 5 个以点分隔的部分。

解码一个 JWT 就等于校验通过了吗？展开

不等于。解码只是把 Base64URL 还原，伪造的 Token 同样能顺利解码。只有签名验证（本工具的"验证"按钮）才能证明 Token 确实由持钥方签发；即便如此，你仍需自行检查 exp、nbf、iss、aud 是否符合预期。

HS256 和 RS256 有什么区别？展开

HS256 是对称算法，签名和验证用同一个密钥，因此能验证的各方也都能伪造 Token。RS256 是非对称算法，私钥签名、公钥验证。只要验证方不应该拥有签发能力，就应该使用 RS256（或 ES256）。

JWT 在 exp 之前能主动吊销吗？展开

本身不能。JWT 是无状态的，签发后直到 exp 都有效，除非服务端维护黑名单（如 Redis）或轮换签名密钥。实践中应保持 Token 有效期尽量短，配合 refresh token 维持长期会话。

浏览器里 JWT 应该存在哪里？展开

优先使用服务端设置的 HttpOnly、Secure、SameSite Cookie。localStorage 可被页面上任意 JavaScript 读取，一旦出现 XSS 漏洞 Token 就会泄露。Cookie 需要 CSRF 防护，但 XSS 窃取通常是更大的风险。

为什么 Token 没过期却被服务端拒绝了？展开

常见原因是时钟偏差。exp 是秒级 Unix 时间戳，服务端通常只允许 30-60 秒的容差。另外检查 nbf（不早于）——签发时 nbf 在未来的 Token 在生效前会被拒绝。还要确认 aud 与客户端请求的 API 匹配。

JWT 解码工具使用指南

在输入框粘贴完整的 JWT 字符串（以 eyJhbGciOi 开头的那一整串）。
工具自动解码 Header 与 Payload，并以 JSON 形式展示。
在 Claims 摘要面板查看 exp / iat / iss / aud / sub，时间会转为可读格式。
如需验证签名，输入对称密钥（HS256/HS512）或 PEM 公钥（RS256），点击验证。

隐私说明

完整说明

JWT 是什么？

**JWT（JSON Web Token）**是一个开放标准（RFC 7519），用于在两方之间以紧凑、URL 安全的字符串形式传递声明（claims）。它是无状态 API 中携带身份与授权状态最常见的方式：服务端签发一个带签名的 Token，后续每次请求携带它，代替 Session 查询。

JWT 不是加密。它只是 JSON 声明的载体，附带一套完整性机制。JWT 标准实际定义了两个经常被混淆的东西：

JWS（JSON Web Signature）——只签名、不加密，任何人可读。野外 99% 的 "JWT" 都是它，也是本工具解码的对象。
JWE（JSON Web Encryption）——真正加密的 Token。区分方法很简单：JWE 有 5 个点分隔的部分（header.encryptedKey.iv.ciphertext.tag），JWS 只有 3 个（header.payload.signature）。

结构：header.payload.signature

一个 JWT 由三段 Base64URL 编码的内容用点号连接而成：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpXYW5lIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwODY0MDB9
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

解码前两段就得到工具界面里显示的 JSON：

Header——Token 的元信息：

{ "alg": "HS256", "typ": "JWT" }

Payload——声明集合。注意这里没有任何机密可言，任何拿到 Token 的人用两行 JavaScript 就能读出来，和本工具做的一样。

Signature——证明。以 HS256 为例，它是 HMAC-SHA256(base64url(header) + "." + base64url(payload), 密钥)。改动 Payload 中哪怕一个字符，签名都会对不上。

编码用的是 Base64URL 而非标准 Base64：+ 换成 -、/ 换成 _、去掉了末尾补位的 =。这正是 Token 可以安全放进 URL、HTTP 头、查询参数而不出编码问题的原因。

签名算法：HS / RS / ES

Header 中的 alg 决定签名如何生成、谁能验证：

算法	类型	密钥模型	典型场景
HS256 / HS384 / HS512	HMAC + SHA-2	同一个密钥既签名又验证	单体应用，签发与验证是同一个服务
RS256 / RS384 / RS512	RSA PKCS#1 v1.5	私钥签名、公钥验证	微服务、第三方验证方、OIDC
ES256 / ES384	ECDSA（P-256/P-384）	同为非对称，密钥和签名更小	现代 API、移动端、资源受限环境
PS256	RSA-PSS	非对称、概率性填充	某些政务 / FAPI 规范强制要求
`none`	不签名	—	应当拒绝。历史上 alg=none 攻击的来源

经验法则：如果验证 Token 的一方不应该拥有签发 Token 的能力，就必须用非对称算法。HS256 下每个能验证 Token 的服务都能伪造 Token——一个被攻破的微服务就等于一个私建铸币厂。

本工具支持用对称密钥验证 HS256/HS512，用 PEM 公钥验证 RS256，底层直接调用浏览器的 Web Crypto API。

你真正应该使用的标准声明

Payload 可以放任何内容，但 RFC 7519 保留了这些键名：

声明	含义	说明
`iss`	签发者	谁创建的 Token，如 `https://auth.example.com`
`sub`	主体	Token 讲的是谁，通常是用户 ID
`aud`	受众	Token 发给谁用的。API 必须拒绝 aud 与自己不匹配的 Token
`exp`	过期时间	Unix 秒。验证库会强制检查它，纯解码永远不会
`nbf`	生效时间	早于该时间戳 Token 无效
`iat`	签发时间	Token 何时创建
`jti`	JWT ID	唯一标识，用于一次性 Token 或黑名单条目

工具的 Claims 面板会把 exp、iat、nbf 渲染成可读的日期时间，一眼就能看出 Token 是否过期或尚未生效。

2026 年仍然在坑人的安全陷阱

1. 信任解码结果。 解码不等于验证。攻击者可以伪造出格式漂亮的 Payload，只有签名校验能证明真伪，而且你自己还得检查 exp/aud/iss 是否符合本 API 的预期。

2. 算法混淆攻击。 经典 CVE 制造机：服务端验证时信任 Token Header 里声明的 alg。攻击者拿一个 RS256 Token，把 Header 改成 HS256，然后用公钥当 HMAC 密钥去签名——服务端恰好也拿公钥验证 HMAC，攻击成功。永远在服务端固定预期算法，就像本工具用 algorithms: [alg] 钉死一样。

3. 弱 HMAC 密钥。 HS256 配一个字典单词密钥，几分钟就会被离线暴力破解——攻击者拿一个合法 Token 就能在不碰你服务器的情况下逐个试密钥。至少使用 256 位随机数（openssl rand -base64 32）。

4. 往 Payload 里塞敏感数据。 那是 Base64，不是加密。Payload 中的 PII、内部 ID、权限明细会跟着 Token 流向所有地方——浏览器开发者工具、日志、代理服务器。

5. 长 Token + 无吊销机制。 被盗的 JWT 在 exp 前一直有效。最佳实践：短时效 access token（5-15 分钟）+ 服务端存储的 refresh token，需要即时吊销时用 jti 黑名单。

6. 存在 localStorage 里。 页面上任何 XSS 都能读光 localStorage 里的所有 Token。HttpOnly Cookie 让 JavaScript 完全碰不到 Token；配合 SameSite 和 CSRF token 使用。

JWT 与不透明 Session Token 对比

	JWT	不透明 Session ID + 存储
验证方式	本地密码学运算，无需查库	每次请求查服务端存储
吊销	困难（黑名单 / 短 exp）	简单（删掉记录即可）
体积	较大（数百字节起）	极小
跨服务	极佳——持有公钥的任何服务都能验证	需要共享会话存储或网关

多个独立服务需要不查库就能验证身份时用 JWT；吊销能力和简单性更重要时用服务端 Session。

本工具如何处理你的 Token

一切都在浏览器中完成：分段拆开后做 Base64URL 字母表转换并解码，JSON 解析后渲染，签名验证直接调用 Web Crypto（crypto.subtle）。没有任何网络请求携带你的 Token 或密钥——这也是为什么可以放心在这里调试真实的环境凭据。