JWT 在线解码、解析与验签
解码 Header 与 Payload、用密钥校验签名、检查过期与安全头，也能直接签发新 Token——密钥只留在浏览器里。
功能特性
支持 HS256/384/512、RS256/384/512、ES256/384/512，用密钥在本地验证签名真伪。
解码 Header / Payload，逐条标出 exp 过期、nbf 未生效、iat 时钟异常与缺失 exp。
编辑 Payload 与 Header、一键补 iat/exp，生成可用的 JWT 并立刻自验。
识别 alg=none、Header 自带 jwk/jku/x5u 等被明确禁止的写法并标红。
密钥与 Token 都只在浏览器内参与运算，不随请求发出。
使用步骤
在左侧粘贴 JWT（可带 Bearer 前缀），立即解码出 Header 与 Payload。
HMAC 填 Secret，RS* / ES* 粘贴公钥 PEM，右侧给出「签名有效 / 无效」结论。
核对 exp 是否过期、是否缺少过期时间，并检查是否有 alg=none 等风险头。
切到「签发 Token」，填 Payload 与密钥，生成后一键「去验签」闭环验证。
适用场景
常见问题
Token 能正常解码，为什么接口还是返回 401？
解码只是 Base64 反转，不代表 Token 合法。401 常见于三种原因：签名不对（换过密钥或不匹配的算法）、已过期（exp 早于当前时间）、以及受众 / 签发者不匹配（aud / iss 校验失败）。把密钥填进来验签，并对照右侧的声明状态逐条排查。
为什么必须校验签名，不能只看内容？
JWT 的 Header 与 Payload 只是 Base64URL 编码，任何人都能在几秒内改掉里面的 sub 或 role 再重新拼一个。只有签名校验通过，才能确认内容确实由持有密钥的一方签发且未被改动。只解码不验签，等于把用户角色交给前端随便写。
支持哪些签名算法？
HMAC 族 HS256 / HS384 / HS512（共用 Secret）、RSA 族 RS256 / RS384 / RS512（私钥签、公钥验）、ECDSA 族 ES256 / ES384 / ES512。不支持的算法会在页面上明确说明，而不是静默给出「无效」。
验证签名时要不要固定算法？
建议固定。默认「跟随 Token 的 alg」方便调试，但生产环境的验签方应当写死自己签发时使用的算法，否则会中两类经典攻击：alg=none（伪造无签名 Token）和 RS/HS 算法混淆（拿公钥当 HMAC 密钥用）。本页的「验签算法」下拉就是给这个场景准备的。
Payload 里的中文解码会乱码吗？
不会。解码走的是 Base64URL → 字节 → UTF-8 严格解码，未转义的原始中文与 emoji 都能正确还原；内容被改动导致解码失败时也会给出明确提示。
密钥会不会被上传？
不会。验签与签发都由浏览器 WebCrypto 在本地完成，密钥、Token 与 Payload 都不会随请求发出，页面也不做任何持久化存储。
JWT 能「解密」吗？和加密有什么区别？
严格说 JWT 是签名不是加密。Header 与 Payload 只做了 Base64URL 编码，任何人拿到 Token 都能直接读出内容，不需要密钥——所以常说的「JWT 解密」其实只是解码。真正的加密令牌（JWE）是另一套规范，本页不做。这也意味着 Payload 里绝不能放密码、身份证号这类敏感信息，它对拿到 Token 的人是明文。