检查 auth provider 给的 token
Auth0、Firebase、Keycloak、AWS Cognito 登录后都会返回 JWT。把 access_token 粘贴进来看看你的应用实际拿到了什么 claims — 用户 ID、scope、什么时候过期。
把任何 JSON Web Token 解码,看到 header、payload、签名 — 或用 HS256/384/512 签出新的 token。本地 HMAC 验证,100% 在你的浏览器中运行。
把任何 JSON Web Token 解码,看到 header、payload、签名 — 或用 HS256/384/512 签出新的 token。本地 HMAC 验证,100% 在你的浏览器中运行。
不会。整个工具就是这个页面里的 JavaScript。粘贴 token,解码在你的浏览器中完成,字节不会离开标签页。可以打开 DevTools → Network 观察,decode 与 verify 期间完全没有任何请求。所以可以安全地粘贴生产环境或客户的 token。
它证明 token 是「持有密钥 (HMAC) 或私钥 (RSA/ECDSA) 的人」签出来的。它不会加密 payload — header 和 payload 只是 base64url 编码的 JSON,任何拿到 token 的人都能读取。签名只防止篡改:payload 改一个字符,签名就对不上。
JWT 通常包含用户 ID、邮箱、scope,有时甚至等同于 session cookie 的内容 — 这些数据绝不应粘贴到陌生人的服务器。iKit Decoder 就是这个页面里早已加载完的 JavaScript。可在 DevTools → Network 中亲眼验证:decode 与 verify 期间没有 fetch、没有 XHR、没有 beacon。
对于 HS256/384/512 token,输入签名密钥即可在本地验证。RS256/ES256 (RSA/ECDSA) 需要服务端库 — 公钥验证需要 PEM 文件,本工具暂不支持。
HS256 在密码学意义上至少需要 32 bytes (256 bits)。任何字符串都可用于测试,但生产环境请使用足够长度的随机密钥。
调试 JWT 最快的方式 — 不上传、不注册、你和 token 之间没有第三方。
粘贴 JWT 后,header、payload、签名同时并列显示。标准 claims (iss、sub、aud、exp、iat) 自动解析时间戳并打上标签。
对 HS256/384/512 的 token,输入密钥即可使用浏览器原生 Web Crypto API 验证,密钥绝不离开你的浏览器标签页。
切换到 Encode 模式,以 JSON 编辑 header、payload,选择算法、输入密钥,立即获得已签名的 token。
JWT payload 通常包含用户 ID、邮箱、权限 — 绝不应粘贴到陌生服务端工具。iKit Decoder 就是这个页面里的 JavaScript,可在 DevTools → Network 中验证。
exp、nbf、iat 等标准 claim 会以人类可读的时间显示,并有清晰的「已过期 / 仍有效」标签,一眼判断 token 是否还能用。
基于浏览器原生 Web Crypto API 与 JSON 解析器 — 算法与 OpenSSL、libjwt、jose 完全一致,行为与所有现代 JWT 库相同。
JWT 就是三段以点分隔的 base64url-encoded JSON,没别的。
JWT 长得像 aaa.bbb.ccc。我们用两个点切成三段:编码后的 header、payload、签名。如果切不出三段,token 就是格式错误。
Header 和 payload 是 base64url 编码的 UTF-8 JSON。Base64URL = Base64 但用 -_ 替换 +/,且省略 padding。我们先把字符替换回去再 atob,然后 JSON.parse。
Header 告诉我们算法 (alg:HS256、RS256 等) 和类型。Payload 包含 claims — 标准的 (iss、sub、aud、exp、iat、nbf、jti) 加上任何自定义字段。每一项都有对应区块显示。
对 HS256/384/512,我们用你输入的密钥重新计算 header.payload 的 HMAC,与第三段签名比对。等同 HMAC(SHA-256, secret, signing_input) 后 base64url 编码。一致 = 签名有效。
你会用上 JWT decoder 的真实情境。
Auth0、Firebase、Keycloak、AWS Cognito 登录后都会返回 JWT。把 access_token 粘贴进来看看你的应用实际拿到了什么 claims — 用户 ID、scope、什么时候过期。
API 拒绝你的请求?解码 token 确认:是否过期 (exp 在过去)?audience claim (aud) 是否符合 API 预期?issuer (iss) 是不是正确的租户?
Stripe、GitHub Apps、Slack 发来的 webhook payload 是以 JWT 形式签名的。收到后粘贴进 Decode 模式 + 共享密钥,确认请求确实来自他们。
集成测试需要一个全新的已签名 JWT?切换到 Encode 模式,编辑 payload(自定义 user ID、自定义 expiry),选择 HS256 + 你的测试密钥,毫秒内拿到 token。无需访问后端。
JWT 通常包含用户 ID、邮箱、scope,有时甚至等同于 session cookie 的内容 — 这些数据绝不应粘贴到陌生人的服务器。iKit Decoder 就是这个页面里早已加载完的 JavaScript。可在 DevTools → Network 中亲眼验证:decode 与 verify 期间没有 fetch、没有 XHR、没有 beacon。
来自 iKit 博客的深度教程与工具对比。
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
不会。整个工具就是这个页面里的 JavaScript。粘贴 token,解码在你的浏览器中完成,字节不会离开标签页。可以打开 DevTools → Network 观察,decode 与 verify 期间完全没有任何请求。所以可以安全地粘贴生产环境或客户的 token。
它证明 token 是「持有密钥 (HMAC) 或私钥 (RSA/ECDSA) 的人」签出来的。它不会加密 payload — header 和 payload 只是 base64url 编码的 JSON,任何拿到 token 的人都能读取。签名只防止篡改:payload 改一个字符,签名就对不上。
三个常见原因:(1) 密钥错了 — JWT 密钥区分大小写,任何空白差异都会导致失败。(2) 算法不一致 — header 写的是 HS256 但原本是用 HS512 签的。(3) Token 签完之后被改过 — 改一个 byte 签名就坏了。请确认 header.alg 与你预期的一致。
目前仅支持 HMAC 系列 (HS256/384/512) 的验证。RS256、ES256 使用公钥加密 — 验证需要 issuer 的 PEM 公钥文件,UI 较为复杂。Decode 仍然可用(header / payload / signature 三段都能正确显示),但 Verify 会提示不支持。RSA/ECDSA 验证已在计划中。
理念一致,默认值不同。iKit Decoder 完全在你的浏览器中运行 (jwt.io 也是,但 iKit 的代码可 view-source、域名没有任何第三方追踪器)。我们对 exp claim 加了清晰的「已过期 / 仍有效」标签、结构化的 claims 注释 (iat / nbf / iss / sub / aud / jti 变成可读的信息行),以及一键复制完整解码结果(可粘贴到 bug 报告)。