安全

JWT 检查器

粘贴一个 JSON Web Token，就能快速查看它的 header、payload、claims、过期时间和签名状态。需要确认签名或生成新的测试 token 时，也可以提供 HMAC secret，或 RSA、ECDSA、EdDSA 密钥。解析、验签和签名都在浏览器内完成，token 和密钥不会发送到服务器。

  • 解析、验签和签名都在浏览器本地完成，不上传 token 或密钥
  • 自动拆分 header、payload 和 signature，并以易读的 JSON 形式展示
  • 支持常见 HMAC、RSA、PS、ECDSA 和 EdDSA 算法；提供匹配密钥后即可验签
  • exp、iat、nbf 会转换成真实日期，方便快速发现过期和时钟偏移问题
工具/JWT 检查器
可选

HMAC 算法需要共享 secret。RSA、PS、ES 和 EdDSA 需要 PEM 或 JWK 格式的密钥材料。

等待输入
在左侧粘贴 token 后，header 和 payload 会立即显示在这里。

功能简介

在一个页面里读取 token、验证签名，并生成新的测试 token。所有操作都在浏览器内完成。

  1. 01

    完整解码 token

    自动把 token 拆成 header、payload 和 signature，并以可读 JSON 展示，不需要手动做 Base64URL 解码。

  2. 02

    支持多种算法验签

    提供正确密钥后，可验证 HS256 到 HS512、RS256 到 RS512、PS256 到 PS512、ES256 到 ES512，以及 EdDSA。

  3. 03

    时间 claim 转成可读日期

    exp、iat、nbf 会显示为真实日期，过期、签发时间异常、服务端时钟偏移等问题会更容易看出来。

  4. 04

    生成已签名 token

    编辑 header 和 payload，选择算法，粘贴匹配密钥，工具会随着输入实时生成新的 token。

  5. 05

    智能识别密钥类型

    可以识别共享 secret、PEM 公钥、PEM 私钥、X.509 证书和 JWK 对象，并根据所选算法用合适的方式导入。

  6. 06

    只在本地处理

    Token 和密钥都留在浏览器里。工具运行期间不会把它们发送到服务器或第三方 API。

如何使用

检查模式用于已有 token，签名模式用于生成测试或调试用的新 token。两种模式共用同一个工作区。

  1. 01

    在检查模式中粘贴已有 token。Header 和 payload 会立即解码显示。

  2. 02

    如果需要确认签名，请把匹配的共享 secret、PEM 公钥或 JWK 粘贴到验签密钥字段。

  3. 03

    需要从可编辑的 header 和 payload JSON 生成新 token 时，切换到签名模式。

  4. 04

    选择算法，并提供匹配的 secret 或私钥。输入变化时，token 会实时重新生成。

  5. 05

    从输出区复制生成的 token，用于 API 请求、测试 fixture 或本地联调。

功能说明

不同任务关注 token 的不同部分。选对模式和字段，调试会直接很多。

  • 没有密钥时，也可以在检查模式中查看 token 里有哪些 claims，以及它是否已经过期。
  • 在检查模式中提供匹配 secret 或公钥，可以确认 token 是否真的来自预期签发方。
  • 在签名模式中生成本地 API、单元测试或 mock 服务用的 token，不必每次都走完整登录流程。
  • HMAC 算法使用同一个共享 secret 进行签名和验签，调试时比较方便。
  • RSA、PS、ECDSA 和 EdDSA 使用私钥签名、公钥验签，因此要准备好对应角色的密钥。
  • 悬停在 payload 里的 exp、iat、nbf 上可查看具体日期，时钟偏移问题通常很快就会暴露。

适合哪些场景

只要应用涉及认证、授权或基于 claim 的路由，这个检查器都能减少你在多个工具之间来回切换。

  1. 登录和权限问题排查

    排查 401 或 403 时，快速检查登录 token 的 subject、roles、scopes、过期时间和签名状态。

  2. 后端 API 联调

    为本地 API、mock 服务和自动化测试生成可预测的签名 token，不用每次都完整登录。

  3. 第三方 token 审查

    解码合作方签发的 token，确认算法、签发方、受众和过期时间是否符合后端预期。

  4. SSO 和 OIDC 排障

    对比不同环境里的 aud、iss、auth_time，找出配置差异，不必直接阅读原始响应。

  5. 安全审查和回归检查

    确认生产 token 使用了预期算法，也确认 payload 中没有误放 secret 或敏感个人数据。

  6. Webhook 和回调校验

    当 webhook 以 JWT 形式传递时，先验证签名、来源和新鲜度，再信任其中内容。

延伸阅读

如果解码后的 header 或 payload 很难阅读，可以打开 JSON 格式化 整理 JSON，然后再复制回签名模式。只想单独查看 token 中某一段 Base64URL 内容时， Base64 编码解码 是尝试编码和解码最快的方式。对于非 JWT 场景，例如 API 请求签名、Webhook 签名、独立 HMAC 摘要，可以打开 HMAC 生成器 。需要给本地 HS256 测试 token 生成一次性 secret 时，可以用 密码生成器 ，不要复用真实凭据。需要比对两次签发的 JWT 解码后 payload，例如检查 claims 变化、scope 收紧或 audience 调整时，可以把两段 JSON 粘进 JSON 差异对比 ，按 JSON Path 直接看到每一处字段差异，长字符串还会展开词级 diff。 如果想看 token 是从哪一段请求里带过来的，可以把完整报文交给 HTTP 报文解析 ，它会把 Authorization 头、Cookie 和 body 一起展开，再回到这里验证 token。 当 token 用 RS256 或 ES256 签名时，验签用的公钥通常放在 X.509 证书里，可以用 证书解码器 查看证书的使用者、有效期和密钥信息，再决定是否信任签发方。

JWT 里面有什么

JWT 由 3 段用点号分隔的内容组成。知道每一段负责什么，排查问题时就能更快定位该看哪里。

  1. Header

    描述 token 类型和签名算法。通常包含 typ 和 alg，有时还会包含 kid，用来标识使用的是哪把密钥。

  2. Payload

    承载 claims，例如 issuer、subject、audience、过期时间，以及你自己的业务数据。它只是 Base64URL 编码，不是加密，所以拿到 token 的人都能解码读取。

  3. Signature

    由 header、payload 和密钥计算而来。它用来发现 token 是否被篡改，并确认签发方；没有正确密钥就无法重新生成同样的签名。

常见标准 claims

RFC 7519 定义了一组注册 claim 名称，大多数签发方都会使用。调试 token 时，可以用下面的参考快速识别常见字段和典型取值。

iss
签发方
标识生成这个 token 的服务或认证机构。接收方通常会把它和可信签发方列表比对。
e.g. https://auth.example.com
sub
主体
标识 token 代表的主体，通常是用户 ID。在同一个签发方范围内应该保持唯一。
e.g. user_1234567890
aud
受众
声明哪个服务或客户端可以使用这个 token。接收方应确认 aud 中包含自己的标识。
e.g. https://api.example.com
exp
过期时间
Unix 秒级时间戳，超过该时间后 token 不应再被接受。多数库会自动拒绝过期 token。
e.g. 1710003600
nbf
生效时间
Unix 秒级时间戳，在该时间之前 token 尚未生效。适合需要在指定时间后才启用的 token。
e.g. 1709996400
iat
签发时间
记录 token 创建时间的 Unix 秒级时间戳。可用于判断 token 年龄和服务间时钟偏移。
e.g. 1709996400
jti
Token ID
Token 的唯一标识。常用于防重放，也方便和服务端审计日志关联。
e.g. a1b2c3d4-...-e5f6
auth_time
认证时间
记录用户实际完成认证的时间。常见于 OpenID Connect 和要求最近登录的 SSO 流程。
e.g. 1709992800

使用建议

把 JWT 当作已签名的明文，而不是私密容器，大多数常见错误就能避免。

  • 在使用 token 里的 claims 前，先用正确的 secret 或公钥验证签名。
  • JWT 是签名，不是加密。不要把密码、密钥或敏感个人信息放进 payload。
  • 生产签名密钥和私钥应放在密钥管理系统里。不要把它们粘贴到浏览器工具、聊天窗口或截图里。
  • 算法必须和密钥类型匹配。HS256 签发的 token 不能用 HS512 验证，RSA 公钥也不能验证 HMAC token。
  • 排查认证问题时，优先检查 exp、iat、nbf，并对比签发方和接收方的系统时间。时钟偏移很容易被忽略。
  • 长期有效 token 应配合 refresh 机制和撤销策略，尽量缩短泄露 token 的可用时间。

边界与注意事项

了解这个工具不覆盖的范围，可以更准确地看待 JWT 安全和兼容性问题。

  • 只支持 compact JWS token，不支持加密的 JWE token。
  • Token 和密钥不会持久化。关闭标签页后，当前数据就会释放。
  • Header 或 payload 中的 JSON 无效时，必须先修复 JSON，才能签名生成 token。
  • 这个工具不是密钥管理服务。长期密钥或主密钥不应粘贴到任何在线工具里，包括这个页面。
  • 非常大的 payload 可能会让编辑器变慢，但处理仍然在本地进行，不会被截断或上传。

常见问题

这里整理了签名与加密的区别、验签失败原因、支持算法，以及数据如何保持本地处理等常见问题。

JWT 是加密的吗？

大多数 JWT 是签名的，不是加密的。拿到 token 的人都可以解码 payload。如果你需要加密，应该使用 JWE，而不是普通 JWS。

为什么签名验证一直失败？

常见原因包括密钥不匹配、算法和 header 中的 alg 不一致、payload 在签名后被改过，或 token 本来就是用另一组密钥签发的。请先对比 header 里的 alg 和你提供的密钥类型。

可以用它处理生产 secret 吗？

建议只用于查看、调试和本地测试 token 生成。生产 secret 和私钥应放在安全的密钥管理系统里，不要放进浏览器工具或共享屏幕。

页面会把我的 token 或密钥发送出去吗？

不会。解析、验签和签名都在浏览器里完成。页面不会通过网络请求把 token 或密钥发送到服务器。

支持哪些算法？

支持 HS256、HS384、HS512、RS256、RS384、RS512、PS256、PS384、PS512、ES256、ES384、ES512 和 EdDSA，覆盖大多数现代后端框架的默认选择。

为什么 exp 和 iat 会显示成日期？

标准中这些 claim 使用 Unix epoch 秒。工具会把它们转换成可读日期，方便快速检查过期和时钟偏移问题。

解码出来的 payload 可以直接信任吗？

只有签名验证通过后才可以信任。单纯解码只能说明 payload 是可读 JSON，不能说明它来自预期签发方，也不能说明传输过程中没有被篡改。

更多相关工具

可以继续处理安全与身份相关任务，例如生成密码、计算哈希，或检查签名。