JWT 解码器
在浏览器中本地解码 JWT header 和 payload。查看 claims、过期时间、issuer 和时间戳，无需把 token 发送到任何地方。
你刚测试了JWT 解码器 — 试试 JSON 格式化 / 验证器 →
什么是 JWT 解码器？
JSON Web Token（RFC 7519）由三个以点号分隔的 Base64URL 编码片段组成：header.payload.signature。标头声明签名算法（alg: HS256、RS256、ES256 等）和令牌类型。负载携带声明 — 注册声明（iss、sub、aud、exp、iat、nbf、jti 见 RFC 7519 §4.1）、公开声明（IANA 注册的名称如 email、name）和私有声明（应用程序定义的任何自定义字段）。签名是使用验证者知道的密钥对串联 header.payload 字符串的 HMAC 或 RSA/ECDSA。此解码器仅在本地读取标头和负载 — 它不验证签名，因为验证需要密钥或公钥，而将其任一粘贴到网络工具中会违反其目的。解码 ≠ 验证：看起来有效的 JWT 可能有伪造的签名、过期的 exp，或某些粗心库接受的 alg: none 标头（2015 年 alg: none 漏洞仍在审计中出现）。在集成工作期间使用此解码器进行检查，绝不要作为授权请求前的网关。
如何使用 JWT 解码器
将完整令牌（三个以点号分隔的片段）粘贴到输入中。工具在点号处分割、Base64URL 解码每个片段，并将标头和负载呈现为格式化的 JSON。iat、nbf 和 exp 等数字声明（Unix 秒数，自 1970 年起）会转换为 ISO-8601 日期及原始值。状态横幅报告过期（now > exp）、尚未有效（now < nbf）或活动。如果解码失败，错误会指出哪个片段格式不正确 — 通常是复制粘贴时截断的令牌、缺少字符的 Base64URL 字符串，或不小心粘贴了不透明的会话 ID 而非 JWT。使用复制来抓取任一片段的 JSON，以便在 jq、Postman 或 IDE 中进一步检查。签名片段显示为原始 — 验证刻意超出范围。
为什么 JWT 检查很重要
当认证失败时，第一个检查步骤总是令牌：存在哪些声明、已过期吗、aud 是否与预期的 API 相符、iss 是否来自正确的授权服务器、客户端是否请求了正确的 scope。没有本地解码器，开发者会将生产令牌粘贴到随机在线网站 — 每次粘贴都是潜在的凭证泄露给拥有该网站日志、分析或后端的任何人。本地 Base64URL 解码可停止泄露。除了调试，JWT 素养对安全审查很重要：发现 alg: none 令牌、注意 exp 未来多年，或在负载中捕捉到意外的角色声明，使用解码器只需数秒，否则需要数分钟。JWT 是持有者令牌 — 拥有即是授权。在检查期间谨慎处理它们的卫生与谨慎对待生产数据库凭证的卫生相同。
常见问题
会验证 JWT signature 吗？
不会。这个页面只会在本地解码 header 和 payload，不会验证 signature 或信任 token。
为什么不用 jwt.io？
TeaFun 强调隐私优先。你的 token 只会停留在浏览器里，不会被上传处理。
会显示哪些时间？
如果 token 内有 exp、iat、nbf，工具会把 Unix timestamp 转成易读的 ISO 日期时间。
把这个工具放进更大的流程里
这些集合会把常见的后续工具和指南整理成同一条工作路径。
浏览相同标签
跳转到其他拥有相同工作流、格式或用途的工具。