JWT 解码与验证
粘贴一个 JSON Web Token，像你的服务器应该做的那样读它：头部与载荷解码成可读的 JSON，时间声明画成时间线——签发、自何时有效、过期、已过期——并且对 HS256、HS384 和 HS512，用你提供的密钥做真正的签名验证。一切都在你的浏览器中进行。令牌是凭据，而在本网站，凭据不会被粘贴进有日志的 AI 对话或陌生人的服务器。
令牌是什么，解码能证明什么
JWT 是三段以点连接的 Base64URL：命名签名算法的头部、装着声明的载荷、以及对前两段的签名。中间那段——人人都想读的那段——是编码，不是加密：Base64 解码器不需要任何密钥就能打开它，这正是令牌绝不能装任何你不会印在海报上的东西的原因。签名添加的是出处证明：改动任何一个声明，HMAC 就不再匹配——前提是验证方真的校验。填满事故报告的失败是：服务器解码后不加验证就信任、库让令牌自己选算法、把“none”令牌当福音接受。本页面复刻诚实的工作流：全部解码并阅读，对照时钟读声明时间线（exp 在过去意味着令牌已死，签名多有效也一样），重视算法警告，最后才验证——在本地验证，密钥与令牌待在同一个浏览器标签里。如果你调试用的密钥来自配置文件，.env 校验器同样不传输地检查那个文件；主打文章 不要让聊天机器人碰你的密钥 解释了为什么整族工作都搬进了浏览器。
常见问题
把生产令牌粘贴到这里安全吗？
这是网上做这件事最安全的地方，也是本工具存在的理由。解码在本页面代码里、你的浏览器中进行：令牌从不传输、存储或记录。对比一下人们实际在用的替代品——AI 对话会把谈话保留在第三方的服务器上；还有那些“在线 JWT 解码器”，它们的服务器能看到你粘贴的一切。令牌在过期之前都是活凭据；粘贴到哪里，就能从哪里被重放。在这里，它哪儿也不去——与 .env 校验器相同的本地规则。
既然任何人都能解码 JWT，为什么这不是安全漏洞？
因为解码从来不是保护手段。JWT 是签过名的陈述，不是加密的陈述：载荷是 Base64URL——一种编码，持有令牌的任何人都能读——安全性在签名里，签名证明陈述由持密钥者签发且未被篡改。经典灾难是开发者把载荷当秘密，或服务器不验签名，让手工改过的载荷畅通无阻。文章 Base64 不是加密 讲了两者之下的编码混淆。
为什么这里能验证 HS256，却不能验证我的 RS256 令牌？
HS256 是对称的：一个共享密钥既签名又验证，所以你输入的密钥可以用 HMAC 在本地校验。RS256 是非对称的：用私钥签名、用配套的公钥验证，而本页面就得向你索要公钥——一个邀请粘贴密钥的页面，教的是最终以泄露私钥收场的习惯。用签发方发布的 JWKS 在你自己的代码或工具里验证 RS256 令牌，永远不要把私钥粘贴到任何网站或对话，包括这一个。
“alg: none”是什么意思，为什么是红色警告？
它表示令牌声明自己未签名——而尊重这一声明的服务器会接受任何人的任何载荷，无需密钥。这是一个真实且反复出现的漏洞类别：信任令牌自身 alg 字段的库，会被递上一个载着管理员载荷的“none”令牌。警告之所以刺耳，是因为正确的反应就该刺耳：none 令牌是未经认证的数据，任何接受它的系统在设计上就存在认证绕过。
签名验证通过了，我就完事了吗？
你证明了令牌由密钥持有者铸造且内容未改。你还没有证明它是给你的（检查 aud 声明）、它是现行有效的（上方时间线显示 exp 与 nbf），或者密钥本身足够强——用“secret”这种可猜密钥的 HS256 会被离线暴力破解，之后任何人都能铸造能通过你校验的令牌。验证是审计中的一行，不是整个审计。