按你自己的时钟判断过期
exp、nbf 和 iat 会变成易读的日期和实时倒计时，并给出明确结论：未过期、已过期、尚未生效或没有过期时间。误写成毫秒的 13 位时间戳会被发现并解释，设在未来的 iat 也一样。
令牌工作台 · 免费
JWT 解码器
粘贴 JSON Web Token，用通俗的语言查看它的头部、载荷和每个声明，并按你自己的时钟检查是否过期。然后用密钥或公钥验证签名，令牌始终不会离开这个标签页。
在浏览器中解码和验证 · 不上传任何内容
报告问题JWT 解码器工作区
编码后的令牌
粘贴 JWT
按收到时的原样粘贴即可：带不带 Bearer、有没有引号、是否跨行都可以。输入时就会在这个标签页中解码。
示例令牌使用 HS256 签名，从加载时起一小时内有效，其密钥已填入下方的验证器。
令牌结构
每一段都有标签和颜色。头部和载荷是 base64url 编码的 JSON；签名是原始字节。
JWT 是由点连接的三个 base64url 段：头部、载荷、签名。粘贴一个令牌，这里就会标出每一段。
令牌状态
–
粘贴一个令牌或加载示例，它的结构、过期时间和算法就会显示在这里。
- 算法
- –
- 密钥模式
- –
- 类型
- –
- 签发
- –
- 过期
- –
- 有效期
- –
第 1 段
头部
哪种算法签署了令牌，使用的是哪个密钥。从 base64url 解码而来。
解码后的头部会显示在这里，其中每个参数都有解释。
第 2 段
载荷
声明。只是编码，并未加密：任何持有令牌的人都能读取。
解码后的载荷会以格式化的 JSON 显示在这里，可直接复制。
声明
每个声明的解释
RFC 7519 注册声明、常见的 OpenID Connect 和 OAuth 声明，以及任何自定义声明。日期以 UTC、你所在的时区和相对当前时间三种方式显示。
载荷中的每个声明都会在这里列出并解释含义，exp、nbf 和 iat 会转换为易读的日期。
签名
验证签名
解码只能显示令牌说了什么。只有用正确的密钥检查签名，才能证明是谁说的，以及内容没有被改动。密钥始终留在这个标签页中。
在上方解码一个已签名的令牌，这里就会出现对应的密钥字段：HS256、HS384 和 HS512 需要密钥，RS、PS、ES 和 EdDSA 需要公钥。
解码不等于验证
任何人都能写出一个解码后包含任意声明的令牌。只有用签发方的密钥检查签名，再检查 exp、nbf、iss 和 aud，令牌才值得信任。切勿只凭解码后的载荷做出访问决策。
确认没有发送任何内容
打开浏览器的开发者工具（F12，Mac 上为 Cmd+Option+I），选择“网络”标签页，然后粘贴一个令牌并验证。没有任何请求携带它：解码是纯 JavaScript，验证使用浏览器的 Web Crypto API。本站的页面浏览统计从不包含你在输入框中输入的内容。
加密令牌保持密封
五段式令牌是 JWE。它的受保护头部可以读取并显示在上方，但声明使用只有接收方持有的密钥加密。没有那个密钥，任何解码器都读不了这些声明，本页面也不会尝试。
这里的一切都在这个标签页中运行。令牌、密钥和公钥只存在于页面内存中：它们从不被存储或发送，在你清除它们或关闭页面后就会消失。输入最多读取 100,000 个字符，密钥最多读取 50,000 个字符。时间以此设备的时钟为准进行比较，不留任何容差，所以在接近 exp 或 nbf 时，你与签发方之间几秒钟的时钟偏差就可能改变结论。
工作原理
三段内容，其中两段任何人都能读。
紧凑格式的 JWT 形如 header.payload.signature，每部分都经过 base64url 编码。前两段是任何人无需密钥就能解码的 JSON，本页面会在你输入时完成这一步。第三段是对前两段的签名，只有用正确的密钥验证它，才能确认令牌是真实的且未被改动。一切都在这个标签页中运行：解码器是纯 JavaScript，验证则使用浏览器内置的 Web Crypto API。
- 01
按原样粘贴令牌
从 Authorization 请求头、Cookie、日志行或身份提供方的调试器中复制它。开头的 Bearer、两侧的引号和换行都会自动去掉，三段内容会分别标注，让你看清头部在哪里结束、载荷从哪里开始。
- 02
读懂头部、声明和时间
两个 JSON 段都会被解码并格式化。每个注册声明以及常见的 OpenID Connect 和 OAuth 声明都会用通俗的话解释，exp、nbf、iat 和 auth_time 会以 UTC、你所在的时区和实时倒计时三种方式显示，令牌是否过期一眼就能看出。
- 03
如果结论很重要，就验证签名
解码无法证明令牌是谁创建的。对于 HS256、HS384 或 HS512，粘贴 HMAC 密钥；对于 RS、PS、ES 和 EdDSA，粘贴签发方的公钥，可以是 PEM 块、JWK 或完整的 JWK 集，Web Crypto 会在这个标签页中完成验证。
专为调试身份验证打造
令牌被拒绝时你要检查的一切。
每个声明都有解释
RFC 7519 中的 iss、sub、aud、exp、nbf、iat 和 jti，以及 name、email、azp、nonce、auth_time、scope、client_id 等常见的 OpenID Connect 和 OAuth 声明，都会说明含义和所属规范。自定义声明会标为自定义，而不是凭空猜测。
与安全相关的警告
alg none、缺失的签名、指向令牌自带密钥的头部参数（jku、x5u、jwk）、严格的库会拒绝的 Base64 填充，以及短于 RFC 7518 要求的 HMAC 密钥，都会被标出，并说明该怎么处理。
真正的签名验证
HS256、HS384 和 HS512 使用共享密钥；RS256 到 RS512、PS256 到 PS512、ES256 到 ES512，以及使用 Ed25519 的 EdDSA，可使用 SPKI PEM、JWK 或按 kid 选取密钥的 JWK 集。密钥类型和算法不匹配时会被拒绝，并指明具体是哪一项。
具体的错误说明，而不是一片空白
段数不对、出现 base64url 字母表以外的字符（附带确切位置）、文本不是 JSON、头部不是对象，每种情况都有专门的解释。五段式的 JWE 会被识别为加密令牌，其头部仍会显示。
数据不离开标签页
解码是纯 JavaScript，验证使用浏览器的 Web Crypto API。没有上传、没有存储，也没有任何携带令牌的请求，你可以在浏览器开发者工具的“网络”标签页中自行确认。
JWT 常见问题
编码不等于加密，解码不等于验证。
什么是 JWT？+
JSON Web Token（RFC 7519）是一种在双方之间传递声明的紧凑格式：由点连接的三个 base64url 段。头部指明算法，载荷包含声明（令牌关于谁、由谁签发、发给谁以及何时过期），签名则让接收方可以确认前两部分出自持有正确密钥的人，并且未被修改。JWT 最常用作 OAuth 访问令牌和 OpenID Connect ID 令牌。
如何解码 JWT？+
在点处把它拆开，对前两段进行 base64url 解码，再把每段结果解析为 JSON。解码就这么简单，所以不需要任何密钥。把令牌粘贴到上方的输入框，输入的同时就会完成解码。base64url 就是普通的 Base64，只是用连字符和下划线代替了加号和斜杠，并去掉了末尾的等号，所以使用标准 Base64 解码器之前，需要先把这两个字符换回来。
在线解码 JWT 安全吗？+
只有在本地解码的页面上才安全。JWT 是一种持有者凭据：谁拿到一个未过期的 JWT，通常就能使用它。本页面在你的浏览器中解码和验证，从不把令牌发送到任何地方；你可以在粘贴之前打开浏览器开发者工具的“网络”标签页自行确认。即便如此，也请尽量使用已过期或测试用的令牌，并且永远不要把生产环境的签名密钥或私钥粘贴到你无法检查的网站上。
任何人都能读取 JWT 载荷吗？+
是的。签名的 JWT 只是编码，并没有加密。base64url 是一种可逆的文本编码，不需要密钥，所以任何看到令牌的人都能读到其中的每个声明。不要把密码、API 密钥，或你不愿让每个令牌持有者看到的个人数据放进 JWT 载荷。如果声明必须保密，令牌就得是经过加密的 JWE。
exp、iat 和 nbf 是什么意思？+
它们都是 NumericDate：自 1970-01-01 00:00:00 UTC 起经过的整数或小数秒数，而不是毫秒。exp 是一个时刻，过了这个时刻令牌就必须被拒绝；nbf 也是一个时刻，在此之前令牌必须被拒绝；iat 是令牌签发的时刻。例如，exp 1767225600 就是 2026-01-01 00:00:00 UTC。许多验证方允许少量时钟偏差，通常在零到五分钟之间。13 位的值几乎总是误写的毫秒时间戳，本页面会把它标出来。
HS256 和 RS256 有什么区别？+
HS256 是使用 SHA-256 的 HMAC。同一个共享密钥既用于签名也用于验证，所以任何能验证令牌的服务也能创建令牌。RS256 是使用 SHA-256 的 RSA 签名。签发方用私钥签名，任何人都可以用公钥验证，提供方通常以 JWK 集的形式发布公钥。HS256 适合自行签发并验证自身令牌的单一系统；RS256、ES256 或 EdDSA 适合跨越信任边界的令牌，例如一个身份提供方对应多个 API。
为什么 alg none 很危险？+
alg none 表示不安全的 JWT：签名段为空，所以任何人都能随意写入声明。规范允许这种令牌，但如果验证方接受它们，或者让令牌自己的头部决定使用哪种算法，就可能被人塞进伪造的令牌。请把 JWT 库配置为只接受你预期的算法，拒绝其他所有算法，包括 none。
如何验证 JWT 签名？+
用正确的密钥，对令牌中原样出现的前两段（头部、一个点、然后是载荷）重新计算或校验签名。对于 HS256，这个密钥就是共享密钥；对于 RS256、PS256、ES256 或 EdDSA，则是签发方的公钥，通常可以在提供方 /.well-known/openid-configuration 文档列出的 jwks_uri 中找到。把其中任意一种粘贴到上方的验证器中即可。真正的验证方还会检查 exp、nbf、iss 和 aud，因为有效的签名只能证明令牌由谁创建，并不能证明它仍然可以接受。
应该用 JWT 还是会话 Cookie？+
传统的会话 Cookie 保存一个随机 ID，服务器在自己的存储中查找它，所以退出登录或撤销访问会立即生效。JWT 自带声明，任何持有密钥的服务无需查询就能验证它，但即使用户退出登录，它在 exp 之前仍然有效，除非你另外加一个拒绝列表。许多网站在服务之间使用短期 JWT，而对浏览器使用服务端会话。两者并不互斥：JWT 本身也可以存放在 Cookie 中。
什么是 JWE？+
JSON Web Encryption 令牌（RFC 7516）是加密的，而不只是签名。它的紧凑格式有五段：受保护头部、加密密钥、初始化向量、密文和认证标签。只有头部可读；声明在密文中，需要接收方的私钥或共享密钥才能解密。本页面能识别 JWE，显示其头部，并明确告诉你没有密钥就无法读取声明。
更多专注好用的工具，随时待命。
探索不断扩充的工具合集，涵盖计算、文档、写作和日常工作。