JWT 解析怎么用？完整使用教程与常见问题

JWT 解析是什么

JWT（JSON Web Token）是一种用于在各方之间传递身份与授权信息的令牌格式，常见于登录认证、单点登录和开放平台接口。它由三部分组成，中间用英文句点分隔：Header（头部）、Payload（载荷）和 Signature（签名）。Header 通常描述令牌类型和签名算法，Payload 存放实际声明数据，比如用户 ID、角色、签发时间和过期时间，Signature 则用于校验令牌是否被篡改。JWT 解析的作用，就是把这段看起来像乱码的字符串拆开，把 Header 和 Payload 从 Base64URL 编码还原成 JSON 文本，并格式化展示出来，方便查看里面到底写了什么。需要说明的是，JWT 的前两部分只是编码，并非加密，任何拿到令牌的人都能解出内容，所以它适合排查问题，但不适合用来存放密码等敏感信息。

JWT 解析怎么用

获取完整的 JWT 字符串。它一般出现在接口请求的 Authorization 请求头中，格式类似 Bearer eyJhbGciOi...，也可能保存在浏览器的 localStorage、Cookie 或接口返回的响应体中。复制时注意把 Bearer 前缀去掉，只保留令牌本身。
把令牌粘贴到解析工具的输入框中。工具会自动识别其中的两个句点，并按句点把令牌切成三段，无需手动拆分。
查看自动解码出的 Header 和 Payload。工具会对前两段做 Base64URL 解码，并整理成带缩进的 JSON，字段名和字段值一目了然。
结合业务判断内容是否符合预期。重点核对签发方 iss、目标受众 aud、过期时间 exp、生效时间 nbf 以及自定义声明，确认没有缺字段或取值错误。
如需对比不同环境的令牌，重复上述步骤即可。Signature 部分会被单独列出，但它是二进制签名经过编码的结果，无法还原成可读文本，只能查看原始字符串。

常见使用场景

接口调试是最典型的场景。调用需要认证的接口时如果返回 401 或 403，可以先解析令牌，确认 exp 是否已经过期、aud 是否与当前服务匹配，往往能快速定位是令牌本身的问题还是服务端校验逻辑的问题。

排查登录状态异常时同样有用。用户反馈“登录后很快掉线”，解析后发现 exp 只设置了很短的有效期，或者 iat 与实际签发时间不一致，就能解释现象来源。开发阶段核对权限声明、租户标识、角色列表等自定义字段，也依赖这类解析。

验证第三方平台返回的令牌内容，确认字段命名与文档一致
检查测试环境与生产环境的令牌声明差异，避免配置串用
教学或技术分享时，直观展示 JWT 的内部结构组成
排查签名算法是否被意外改成 none，提前发现安全隐患

使用注意事项

JWT 的 Header 和 Payload 只是 Base64URL 编码，不是加密，任何人都能解码，不要把密码、身份证号等敏感数据放进声明中。
解析成功不代表令牌有效。工具只做解码，不校验签名，也不判断是否过期，令牌是否被服务端接受仍需以实际请求结果为准。
避免在公共电脑或共享环境粘贴生产环境的真实令牌，令牌一旦泄露，在有效期内可能被直接用于冒充身份。
复制令牌时不要带 Bearer 前缀和多余空格，否则分段会错位，导致解析失败或 JSON 格式异常。

常见问题

为什么 Signature 部分解析不出内容？

签名是对 Header 和 Payload 使用密钥或公私钥计算出的结果，本质是二进制数据，经过 Base64URL 编码后呈现为一段字符串。它不像前两部分那样是 JSON 文本，所以解码后不会得到可读内容，只能看到原始编码值。要验证签名是否有效，需要在服务端用对应密钥重新计算并比对。

解析出来的时间字段为什么是一串数字？

JWT 规范中的时间声明 exp、iat、nbf 使用 Unix 时间戳，单位是秒，而不是常见的日期字符串。把该数值转换成日期时间即可阅读，注意它是 UTC 时间，需要按本地时区换算。部分实现会额外提供可读时间字段，属于自定义声明，并不在标准范围内。

解析失败或提示格式错误怎么办？

先确认字符串是否完整，JWT 必须恰好包含两个句点、三段内容，缺一段或复制时被换行截断都会失败。其次检查是否混入了 Bearer 前缀、引号或空格。如果令牌使用了非标准的编码方式，或者 Payload 本身就是加密的 JWE 格式，也无法按普通 JWT 解码，需要改用对应的解密工具处理。