JWT Decoder

JWT Decoder / Encoder

把任何 JSON Web Token 解码,看到 header、payload、签名 — 或用 HS256/384/512 签出新的 token。本地 HMAC 验证,100% 在你的浏览器中运行。

JWT Decoder / Encoder — TL;DR

把任何 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。

Header

Payload

签名

标准 Claims


            

验证 HMAC 签名

对于 HS256/384/512 token,输入签名密钥即可在本地验证。RS256/ES256 (RSA/ECDSA) 需要服务端库 — 公钥验证需要 PEM 文件,本工具暂不支持。

为什么选择 iKit JWT Decoder

调试 JWT 最快的方式 — 不上传、不注册、你和 token 之间没有第三方。

三段一次到位

粘贴 JWT 后,header、payload、签名同时并列显示。标准 claims (iss、sub、aud、exp、iat) 自动解析时间戳并打上标签。

本地 HMAC 验证

对 HS256/384/512 的 token,输入密钥即可使用浏览器原生 Web Crypto API 验证,密钥绝不离开你的浏览器标签页。

签出自己的 token

切换到 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 解码实际是怎么工作的

JWT 就是三段以点分隔的 base64url-encoded JSON,没别的。

  1. 1

    用点分隔成三段

    JWT 长得像 aaa.bbb.ccc。我们用两个点切成三段:编码后的 header、payload、签名。如果切不出三段,token 就是格式错误。

  2. 2

    对每段做 base64url 解码

    Header 和 payload 是 base64url 编码的 UTF-8 JSON。Base64URL = Base64 但用 -_ 替换 +/,且省略 padding。我们先把字符替换回去再 atob,然后 JSON.parse。

  3. 3

    结构化呈现

    Header 告诉我们算法 (alg:HS256、RS256 等) 和类型。Payload 包含 claims — 标准的 (isssubaudexpiatnbfjti) 加上任何自定义字段。每一项都有对应区块显示。

  4. 4

    验证 (仅 HMAC)

    对 HS256/384/512,我们用你输入的密钥重新计算 header.payload 的 HMAC,与第三段签名比对。等同 HMAC(SHA-256, secret, signing_input) 后 base64url 编码。一致 = 签名有效。

常见 JWT 调试场景

你会用上 JWT decoder 的真实情境。

检查 auth provider 给的 token

Auth0、Firebase、Keycloak、AWS Cognito 登录后都会返回 JWT。把 access_token 粘贴进来看看你的应用实际拿到了什么 claims — 用户 ID、scope、什么时候过期。

调试 401 Unauthorized

API 拒绝你的请求?解码 token 确认:是否过期 (exp 在过去)?audience claim (aud) 是否符合 API 预期?issuer (iss) 是不是正确的租户?

验证 webhook 签名

Stripe、GitHub Apps、Slack 发来的 webhook payload 是以 JWT 形式签名的。收到后粘贴进 Decode 模式 + 共享密钥,确认请求确实来自他们。

生成测试用 token

集成测试需要一个全新的已签名 JWT?切换到 Encode 模式,编辑 payload(自定义 user ID、自定义 expiry),选择 HS256 + 你的测试密钥,毫秒内拿到 token。无需访问后端。

为什么本地 JWT 解码很重要

JWT 通常包含用户 ID、邮箱、scope,有时甚至等同于 session cookie 的内容 — 这些数据绝不应粘贴到陌生人的服务器。iKit Decoder 就是这个页面里早已加载完的 JavaScript。可在 DevTools → Network 中亲眼验证:decode 与 verify 期间没有 fetch、没有 XHR、没有 beacon。

  • Decode / verify 期间零网络请求 — 可在 DevTools 中验证。
  • 你输入的验证密钥仅保存在浏览器内存中,清除/刷新即消失。
  • 可安全用于生产 token、客户 access token、webhook secret。

相关教程

来自 iKit 博客的深度教程与工具对比。

常见问题

这安全吗?我的 JWT 会被上传吗?

不会。整个工具就是这个页面里的 JavaScript。粘贴 token,解码在你的浏览器中完成,字节不会离开标签页。可以打开 DevTools → Network 观察,decode 与 verify 期间完全没有任何请求。所以可以安全地粘贴生产环境或客户的 token。

JWT 签名实际上验证的是什么?

它证明 token 是「持有密钥 (HMAC) 或私钥 (RSA/ECDSA) 的人」签出来的。它不会加密 payload — header 和 payload 只是 base64url 编码的 JSON,任何拿到 token 的人都能读取。签名只防止篡改:payload 改一个字符,签名就对不上。

为什么解码正常但验证失败?

三个常见原因:(1) 密钥错了 — JWT 密钥区分大小写,任何空白差异都会导致失败。(2) 算法不一致 — header 写的是 HS256 但原本是用 HS512 签的。(3) Token 签完之后被改过 — 改一个 byte 签名就坏了。请确认 header.alg 与你预期的一致。

RS256、ES256 等公钥算法支持吗?

目前仅支持 HMAC 系列 (HS256/384/512) 的验证。RS256、ES256 使用公钥加密 — 验证需要 issuer 的 PEM 公钥文件,UI 较为复杂。Decode 仍然可用(header / payload / signature 三段都能正确显示),但 Verify 会提示不支持。RSA/ECDSA 验证已在计划中。

和 jwt.io 有什么不同?

理念一致,默认值不同。iKit Decoder 完全在你的浏览器中运行 (jwt.io 也是,但 iKit 的代码可 view-source、域名没有任何第三方追踪器)。我们对 exp claim 加了清晰的「已过期 / 仍有效」标签、结构化的 claims 注释 (iat / nbf / iss / sub / aud / jti 变成可读的信息行),以及一键复制完整解码结果(可粘贴到 bug 报告)。