JWT 解码工具 - 在线解析 Token、检查过期时间与验证签名

功能特点

• 解析 JWT Header、Payload 和签名片段
• 检查 exp 过期时间，快速判断 Token 是否仍然有效
• 支持 HS256 签名生成和验证，辅助接口鉴权调试
• 区分 Base64URL 解码、exp/iss/aud/nbf 声明检查和 HS256 签名验证，不把 Payload 当作可信身份依据
• 本地处理 Token 内容，适合开发和测试环境排查

使用方法

1. 粘贴需要解析或验证的 JWT Token
2. 查看 Header、Payload、Base64URL 解码结果以及 exp/iss/aud/nbf 等声明
3. 根据需要填写脱敏密钥生成或验证 HS256 签名，再由服务端按算法和权限策略复核

示例输入

• 解码 Header 和 Payload

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJleHAiOjQxMDI0NDQ4MDB9.<SIGNATURE>

  适合查看 alg、typ、sub 和 exp 等字段；示例签名不代表真实有效。

• 检查 exp 过期时间

  {"sub":"user_123","iat":1710000000,"exp":1710003600}

  适合定位 Token 过期、服务器时间漂移和秒级时间戳误用。

• HS256 本地签名

  Header: {"alg":"HS256","typ":"JWT"}
  Payload: {"sub":"123"}
  Secret: <LOCAL_SECRET>

  适合开发环境联调；不要使用生产密钥或把生成结果当作安全审计结论。

• iss / aud / nbf 声明检查

  {"iss":"https://issuer.example","aud":"orders-api","nbf":1710000000,"exp":1710003600}

  适合核对签发方、受众、生效时间和过期时间；每个声明是否可信仍由服务端策略和签名验证决定。

示例输出

• 解码 Header 和 Payload

  Header: {"alg":"HS256","typ":"JWT"}
  Payload: {"sub":"123","exp":4102444800}
  签名：未验证

• 检查 exp 过期时间

  iat: 2024-03-09T16:00:00.000Z；exp: 2024-03-09T17:00:00.000Z；有效期：3600 秒

• HS256 本地签名

  示例 JWT：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.<signature>

• iss / aud / nbf 声明检查

  声明检查：iss=https://issuer.example；aud=orders-api；nbf=1710000000；exp=1710003600；仍需服务端验证签名与授权策略

常见错误

• JWT 解码只能读取 Header 和 Payload，不等于验证签名，也不能证明 Token 可信。
• exp、iat、nbf 通常使用 Unix 秒级时间戳，误传毫秒值会造成立即过期或超长有效期。
• HS256、RS256 和 ES256 的密钥类型不同，算法不匹配会导致签名验证失败。
• JWT 的 Header 和 Payload 可以被读取，不能因为内容看起来合理就跳过签名、算法、iss、aud 和过期时间验证。
• 只检查 exp 仍不够，还要结合 iss、aud、nbf、权限声明和服务端撤销策略判断登录态。
• 不要在在线工具中粘贴生产 Token、刷新 Token 或签名密钥，即使页面只做本地处理也应先脱敏。

适用场景

• JWT 解码在线
• Token exp 过期检查
• 接口鉴权排查
• 前后端登录态联调
• HS256 签名测试
• Claims 字段检查

实操检查

• 解码、Claims 和签名是三件事

  解码路径只读取三段 JWT 的 Header 与 Payload，Claims 检查还会标出 exp、nbf 等字段状态；这些操作不会因为能解析 JSON 就证明签名可信。

• 核对 exp 单位和 HS256 边界

  过期时间按 JWT NumericDate 秒值转换为日期；签名路径只在本地生成和验证 HS256，使用前要确认服务端算法、密钥和 Claims 规则，并且不要粘贴生产 Token 或密钥。

页面专属核验

使用前与操作中

• 先区分 Header/Payload 解码、Claims 检查和 HS256 签名验证，不把能解析 JSON 当作可信。
• 签名验证前确认算法、密钥、NumericDate 秒单位和服务端 Claims 规则。
• 优先使用虚构 Token；不要把生产 Token、密钥或可识别用户信息粘贴到调试页面。

结果出来后

• Header、Payload 和 exp/nbf 等 Claims 是否与实际签发方和协议约定一致？
• 签名验证是否使用正确算法和密钥，并在服务端再次执行，而不是只看本地页面结果？
• Token 是否已经脱敏、过期或仅用于测试，且没有被复制到日志、URL 或分享链接？

相关工具

• Hash 与签名：统一生成文本 Hash、文件 Hash、HMAC 签名和 Bcrypt 密码哈希
• 文本编码转换：统一转换 Base64、Hex、Binary、Unicode Escape、UTF-8 Hex、ASCII、HTML Entity 和 Morse
• 时间戳转换：Unix 时间戳与日期时间相互转换
• JSON 工具：统一处理 JSON 格式化、校验、树形查看、Schema、CSV 转换、AI 响应分析和 JSON 修复

工具边界

• 本地解码不等于签名验证，不会证明 Token 可信。
• 当前 HS256 工作台不能替代 RS256 或 ES256 的公钥验证。
• 不要提交生产 Token、刷新 Token 或签名密钥。

与相似工具的区别

• Hash 与签名：JWT 工作台理解 Header、Payload、exp 和 HS256 结构；Hash 工具只计算摘要/HMAC，不会验证令牌声明与格式。

安全与兼容性

• 解码和 HS256 计算在浏览器本地完成；不要粘贴生产访问令牌、刷新令牌或签名密钥。
• 解析 Payload 不代表可信，服务端必须固定允许算法、验证签名、iss、aud、exp、nbf，并安全获取密钥。

下一步排查

1. 先解码 Header 和 Claims，确认 alg、iss、aud、exp、nbf。
2. 用时间戳工具核对秒级或毫秒级单位和时区。
3. 再用 Hash、Headers 或 cURL 工具复现鉴权请求。

常见问题