JSON Web Token 由三段 base64url 文本组成，段与段之间用点分隔：头部说明它是如何签名的，载荷是一组声明，末尾是签名。这一页会把三段都读出来，逐条说明每个声明的含义，把时间类声明换算成日期，并在你提供密钥时核对签名是否真的匹配。
JWT 解码器与哈希生成器 - Danfio
https://danfio.com/tools/jwt-decoder/ - 从本页打印
已解码的令牌
8 条声明
由 https://danfio.com 签发，面向 danfio-tools，主体为 user_1024。过期时间 2100-01-01 00:00:00 UTC（73 年后）。
Danfio 中文在线工具头部
{
"alg": "HS256",
"typ": "JWT",
"kid": "danfio-demo-2026"
}
载荷
{
"iss": "https://danfio.com",
"sub": "user_1024",
"aud": "danfio-tools",
"iat": 1767225600,
"nbf": 1767225600,
"exp": 4102444800,
"jti": "8f0c1c0e-6a2b-4e5f-9a17-3d5b7c9e1f20",
"scope": "tools:read reports:read"
}
声明
iss https://danfio.com
签发者：谁创建了这枚令牌
sub user_1024
主体：这枚令牌是关于谁的
aud danfio-tools
受众：这枚令牌发给谁 —— 服务器会检查它是否与自己一致
iat 1767225600
签发时间：令牌创建的时刻
2026-01-01 00:00:00 UTC（10 个月前）
nbf 1767225600
生效时间：在这个时刻之前必须拒绝该令牌
2026-01-01 00:00:00 UTC（10 个月前）
exp 4102444800
过期时间：过了这个时刻就必须拒绝该令牌
2100-01-01 00:00:00 UTC（73 年后）
jti 8f0c1c0e-6a2b-4e5f-9a17-3d5b7c9e1f20
JWT ID：这枚令牌的唯一名字，便于单独撤销
scope tools:read reports:read
授予的权限，使用 OAuth 2.0 的 scope 语法
签名
xTefkG02o4JtCQIgIIC0IVb-h7sIDUkxaUkn1l_r-yA（32 字节，base64url）
HS256：没有提供密钥，所以只展示了签名，没有校验。粘贴密钥或十六进制密钥，就能知道它是否匹配。
完整的解读结果，可以直接粘贴进工单 —— 也可以点复制按钮一次拿走全部内容。
同一页面还能用 SHA-256、SHA-1 和 MD5 为文本计算哈希，并与你粘贴的校验和进行比对。所有计算都在浏览器里完成，令牌不会被发送到任何地方——这也是在这里粘贴令牌还能说得过去的唯一理由。
令牌里的声明不需要密钥就能读，从来如此：前两段是 base64url，只是一种编码，不是一把锁。这一页会解码全部三段，给每条声明标注名称，把表示时间点的声明换算成可读日期，并单独检查 HS256 签名是否与你提供的密钥匹配。
声明名称与 NumericDate 的单位来自 RFC 7519，签名校验遵循 RFC 7515：时间以 1970 年以来的整秒计，而不是毫秒。整个过程没有账号，也没有服务器参与，令牌就在标签页里解析，这也是在这里粘贴令牌还能说得过去的唯一理由。
解码与验证被刻意分开，因为能读懂一个令牌，并不能证明它是谁写的。页面会把 `alg: none` 以及头部自带密钥的情况标为风险，而不是照单全收。想弄清一个过期或被拒的令牌，分清“它说了什么”与“它是否真实”，正是全部关键。
前两段是 base64url，只是一种编码，不是一把锁：任何拿到令牌的人都能读出其中的每一条声明，不需要密钥，也不需要任何技巧。载荷本身没有加密，假装它加密了，正是令牌里最终会塞进本不该出现的数据的原因。
签名提供的是来源，而不是保密性。它是一个只有签发方才能产出的值，因此校验签名的一方能确认：这些声明出自持有密钥的人之手，并且自签署以来没有改动。页面之所以把两种解读分开，就是为了这个：令牌说了什么，以及签名是否与你给出的密钥匹配。
这一族里最古老的漏洞是 `alg: none`，即令牌宣称自己未签名。相信头部的校验方会满足任何人的任何要求，所以面板把这种情况当作风险发现来处理，而不是客客气气地解码。第二种是头部自带密钥（`jwk`、`jku`、`x5u`）：从令牌里取密钥的校验方，实际上是在拿令牌验证它自己。
载荷是一个 JSON 对象，注册声明的名字都只有一个词：`iss` 是签发者，`sub` 是主体，`aud` 是受众，`exp` 是必须拒绝该令牌的时刻，`nbf` 是它开始生效的时刻，`iat` 是签发时刻，`jti` 则是这枚令牌的名字，便于撤销。其余字段，例如 `scope`、`roles`、`email`，以及各家服务自创的内容，都属于签发方与应用之间的约定。
四个时间类声明都是 NumericDate 值：1970 年以来的整秒，而不是毫秒。这一个细节解释了围绕令牌的大部分困惑——把 `exp` 的 1789650000 按毫秒解读，时间会落在 1970 年，看上去像令牌过期，实际上是单位弄错了。页面会把它们逐个打印成日期，并标出距今多久或还有多久。
受众声明最常解释一次拒绝。签发给 `api.example.com` 的令牌，在 `example.com` 上就是无效的，签名再正确也一样；而跳过 `aud` 检查的服务，会接受为别人签发的令牌。
哈希把任意输入变成一个固定长度的值。同样的文本永远得到同样的摘要，改动一个字符就会改变全部，而这个值无法再变回文本。这使它成为一种指纹：校验和确认下载完整到达，摘要确认两份文件是同一份文件。
该用的是 SHA-256。SHA-1 和 MD5 在安全性上都已失效——两者都有公开的故意碰撞——但作为非对抗场景的校验和依然可用：S3 的 ETag 是 MD5，Git 用 SHA-1 给对象命名，很多管道也比较 MD5 值。页面把三种都算出来并标注清楚，因为“匹配别人给你的值”和“保护你正在创建的值”是两件不同的工作。
哈希也不是签名。把密钥与消息拼在一起做哈希，`hash(secret + message)`，看起来像认证，其实不是：这种构造可以被长度扩展，任何人都能在不知道密钥的情况下往消息后面追加内容。HMAC 正是为了解决这个问题，本页校验 HS256 签名用的就是它，并且作用在当初被签名的精确字节上。
示例使用页面自带的默认输入，只改设置；下面的结果与你在页面上看到的完全一致。
要做什么: 解码 JSON Web Token 并校验签名
已解码的令牌
8 条声明
由 https://danfio.com 签发，面向 danfio-tools，主体为 user_1024。过期时间 2100-01-01 00:00:00 UTC（73 年后）。
算法: HS256 · 密钥 ID: danfio-demo-2026 · 声明数: 8 · 签名: 未校验
声明全部可读——把它们列出来正是重点——但在提供密钥之前，签名始终处于未校验状态。面板会明说这一点，而不是暗示令牌可信。
要做什么: 解码 JSON Web Token 并校验签名 · 密钥（仅用于校验签名）: ••••••••
已解码的签名令牌 —— 签名匹配
8 条声明
由 https://danfio.com 签发，面向 danfio-tools，主体为 user_1024。过期时间 2100-01-01 00:00:00 UTC（73 年后）。
算法: HS256 · 密钥 ID: danfio-demo-2026 · 声明数: 8 · 签名: 匹配
示例令牌故意用公开的密钥签名，所以这段过程值得走一遍：签名匹配；而在载荷里改动一个字符，匹配立刻失败。
要做什么: 为文本计算哈希（SHA-256、SHA-1 和 MD5） · 要哈希的文本: abc
同一段文本的 SHA-256、SHA-1 与 MD5
3 个字符，3 个字节
三种摘要针对的是同一段字节；除非你要匹配的东西已经在用更老的算法，否则该用 SHA-256。
UTF-8 字节数: 3 · SHA-256: ba7816bf8f01cfea... · 提供的校验和: 未提供
同一段三个字节的文本得到三种摘要。“abc” 的 SHA-256 是规范里的第一个示例，可以拿来与任何其他实现对照。
要做什么: 为文本计算哈希（SHA-256、SHA-1 和 MD5） · 要哈希的文本: abc · 要比对的校验和: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
同一段文本的 SHA-256、SHA-1 与 MD5
3 个字符，3 个字节
三种摘要针对的是同一段字节；除非你要匹配的东西已经在用更老的算法，否则该用 SHA-256。
UTF-8 字节数: 3 · SHA-256: ba7816bf8f01cfea... · 提供的校验和: 匹配 SHA256
粘贴别人交给你的值，页面会告诉你它匹配三种摘要中的哪一种。比对针对整个摘要，统一转成小写并忽略空格，这也是校验和常见的到达方式。
载荷对任何持有令牌的人都是可读的，所以在这里解码不会暴露令牌本身没有暴露的信息。但令牌仍然是持有即用的凭证：任何人拿到一枚仍然有效的令牌就能使用它，因此不要把它粘贴到你无法控制的页面。这一页没有可发送数据的服务器，解码就在你自己的浏览器标签页里进行，粘贴的内容不会被存储或记录——这也是本站所有工具遵循的标准。
不代表。签名证明来源与完整性，却不说明声明本身是否合适：过期令牌可以有完全有效的签名，发给别的受众的令牌也可以有，用已泄露密钥签出的令牌同样可以有。验证方仍然必须检查 `exp`、`nbf` 和 `aud`，自己查出密钥而不是相信头部，并拒绝 `alg: none`。
因为校验它们需要签发方的公钥，以及 RSA 或椭圆曲线运算，而这一页只计算 HMAC-SHA-256。与其显示一个无法自证的绿色对勾，页面会说明它看到的是哪种算法，并明确签名未校验。要验证 RSA 或 ECDSA 令牌，请使用了解该算法与签发方 JWKS 文档的库；这里会展示前两段上的签名，方便你复制过去。
要么你给的密钥不是签发这枚令牌的那把，要么令牌在签名之后被改过。校验针对前两段的精确字节，所以改动载荷里的一个字符——角色、用户 ID、过期时间——都会让重算结果不同。这正是签名的意义，也是为什么“我能改自己的令牌而服务器照样接受”属于安全事故，而不是特性。
通常是把它当成了毫秒。`exp`、`nbf`、`iat` 和 `auth_time` 都是 1970 年以来的整秒：把 1789650000 按毫秒解读，时间会落在 1970 年 1 月，看起来自然像过期。另一个常见原因是签发方与验证方的时钟存在偏差，所以多数库允许几十秒到一分钟的容差，而不是要求两边完全一致。
只在有明确理由时用。令牌自带声明，验证时无需查库，这让它很快，也让它难以撤销：在过期之前，它一直有效。如果会话必须能立即撤销，要么把令牌有效期设短并配合刷新令牌，要么继续使用服务端会话。`jti` 声明的作用就是给某一枚令牌命名以便拉黑，但那又回到了查库。
新用途选 SHA-256。SHA-1 与 MD5 在安全性上已经失效——两者都有公开的碰撞实例——因此不应使用在“有人能从构造相同摘要中获利”的场合。但如果要匹配别处产出的值，它们仍是正确答案：S3 的 ETag 是 MD5，Git 对象名是 SHA-1，很多数据管道也比较 MD5 校验和。匹配旧值与保护新值是两件不同的事。
不够，原因就是速度：SHA-256 被设计得很快，现代显卡每秒可以尝试数十亿次猜测。密码需要刻意放慢、占用内存的函数，例如 argon2、scrypt 或 bcrypt，并为每个用户使用独立的盐值，这样两个使用相同密码的用户也不会得到相同的值。这一页的哈希用于核对校验和，而不是存储凭证。
最近复核于 2026-09-16.
本页在您的浏览器本地运行，请保留原文件备份；不涉及财务建议。 阅读完整免责声明。