CodeKitHub工具介绍
JWT（JSON Web Token）是一种紧凑、URL安全的字符串，用于在两方之间传递声明信息——最常见的用途是登录后的身份令牌。它由三段用点号分隔的部分组成：Header（算法和令牌类型）、Payload（实际的声明内容——用户ID、角色、过期时间等）、Signature（服务端用来验证令牌未被篡改的签名）。
Header 和 Payload 只是 Base64URL 编码的 JSON——不是加密——所以任何人都能不需要密钥就解码读出内容。只有 Signature 部分需要密钥才能验证。这正是本工具做的事：解码可读的两部分并格式化展示，不尝试验证签名。
为什么使用它？
- 即时得到格式化的 JSON——不用再手动拆分字符串、手工 Base64 解码。
- 自动过期检测：如果 Payload 里有"exp"声明，会转换成可读日期，并标注是否已过期。
- Header 和 Payload 可分别一键复制。
- 100% 浏览器本地解码——token 不会被传输，即使是生产环境的真实 token 也能放心使用。
- 不做也不声称做签名验证——这是调试/查看工具，不是验证器。
使用方法
- 把 JWT 完整粘贴进输入框（包括全部三段，用点号分隔）。
- 输入时 Header 和 Payload 会自动解码显示。
- 如果 token 带"exp"声明，会显示具体过期时间和是否已过期。
- 点击每个框下方的"复制"按钮即可复制该部分 JSON。
示例
输入
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjoxNzAwMDAwMDAwfQ.dQw4w9WgXcQ输出
Header: {"alg": "HS256"}
Payload: {"sub": "1234", "name": "John Doe", "exp": 1700000000}第三段（Signature）不会被解码或校验——它是服务端用来验证真实性的不透明哈希值。
实用建议
- 排查"token 无效"错误时：先解码 payload 查看"exp"声明——token 过期是最常见的原因，但从报错信息本身往往看不出来。
- 查看第三方 API 令牌到底装了什么：很多 API 返回的 access token 表面上看是一串乱码的 JWT——用本工具解码就能看到实际拿到的权限范围、用户ID或过期时间。
- 永远不要假设 JWT 是加密的：开发时如果在解码后的 payload 里看到敏感数据（邮箱、内部ID），这是个信号——应该把这类数据挪到服务端处理，而不是指望客户端不去读它。
Payload里常见的声明字段
| 字段 | 含义 |
|---|---|
| sub | 主体——通常是令牌代表的用户ID |
| exp | 过期时间（Unix时间戳）——超过这个时间令牌失效 |
| iat | 签发时间——令牌是什么时候创建的 |
| iss | 签发方——哪个服务/服务器签发了这个令牌 |
| aud | 受众——这个令牌是给哪个服务用的 |
| role / roles / scope | 自定义字段——授予用户的权限或角色（不是JWT标准的一部分，但极其常见） |
常见问题
这个工具会验证 JWT 的签名吗？
不会。验证签名需要签发方持有的密钥（对称或非对称密钥对），只有签发服务器自己有。本工具只解码 Header 和 Payload 这两个人类可读的部分，方便你查看声明内容和过期时间，不需要任何密钥。
把真实的生产环境 JWT 粘贴进来安全吗？
解码完全通过浏览器 JavaScript 本地完成——token 不会发送到任何服务器，包括本站。不过还是建议把 token 当密码对待：不要粘贴到不信任的工具里，也避免分享包含敏感声明的解码截图。
为什么不需要密码任何人都能读出我的 JWT 内容？
这是设计使然——JWT 的 Header 和 Payload 只是 Base64URL 编码，不是加密。编码不等于加密，它只是让 JSON 能安全地在 URL 里传输。永远不要把密码、信用卡号这类敏感信息直接放进 JWT payload——假设任何拿到 token 的人都能读到里面的内容。
"exp"声明是什么意思，为什么重要？
"exp"是令牌的过期时间，用 Unix 时间戳表示（从1970年至今的秒数）。这个时间一过，服务端会拒绝该 JWT，强制客户端重新登录。本工具会把它转换成可读日期并标注是否已过期，排查"为什么突然被登出"这类问题时很有用。
为什么我的 token 显示 JSON 解析错误？
要么这不是合法的 JWT（应该正好是三段用点号分隔），要么是被截断或修改过——常见原因是复制时 token 被意外换行分割，或者结尾字符丢失。