JWT 编码器
用声明组装令牌，并真正为它签名 · 在此标签页内运行，从不发送到任何地方
头部
载荷
签名密钥
密钥用完即弃——不会保存在这个浏览器里，也不会发送到任何地方。
签名密钥能造出你的系统会接受的令牌。生产密钥请在自己的环境里用。
HS256
已签名令牌
已签名的令牌会显示在这里。生成过程不上传任何内容：签名由这个浏览器计算。
JWT 编码器 的工作原理
这是一个真正产出已签名令牌的 JWT 编码器，而不是 base64 的仿制品。用 JSON 写好头部和载荷，选择算法，再粘贴 HS 系列所需的共享密钥，或 RS、PS、ES 所需的 PKCS#8 私钥——签名由你自己浏览器的 WebCrypto 计算。有效期、签发时间和「不早于」都可以用预设一键打上，你再也不用手工换算 epoch 秒数。
用 JSON 写好头部和载荷，选一个算法，令牌就会随着你的输入组装并签名。有效期预设会以同一个时刻把 iat、exp（以及可选的 nbf）打进载荷，因此三者绝不会相差一秒——这类问题往往只在别人系统的时钟偏差容忍范围里才暴露出来。
无论你的头部怎么写，alg 始终按你选定的算法写入。这不是为了方便：头部声称一种算法、签名却用另一种算法生成，正是 JWT 最著名漏洞的起点，而这条规则不会让任何正当的令牌造不出来。你写的其他头部字段都会原样保留。
比哈希更短的 HS 密钥默认会被拒绝——RFC 7518 要求 HS256 至少 32 字节、HS384 至少 48 字节、HS512 至少 64 字节，而浏览器用四个字符也照签不误，尽管结果在离线状态下几秒钟就能被破解。这项检查可以关掉，因为复现一个弱令牌有时正是你要做的事。
签名密钥的处理方式与解码器对待验证密钥的方式相同，而且更加谨慎：绝不写入 localStorage，刷新后不会恢复，不会出现在任何分析事件里，也没有任何后端能收到它。在使用 JWT 的系统中，签名密钥是最危险的秘密，所以对于生产密钥，在自己的环境里签发令牌仍是更好的习惯。
常见问题
把签名密钥粘贴到这个编码器里安全吗？
密钥只在你自己的标签页里使用，用完即弃：不写入存储，不进入任何分析事件，也没有任何后端能收到它。话虽如此，在使用 JWT 的系统中，签名密钥是最危险的秘密——谁拿到它，谁就能造出你的服务会接受的令牌。对于生产密钥，在自己的环境里签发令牌仍是更好的习惯；这个工具是为开发、测试和学习准备的。
它能用哪些算法签名？
可以用共享密钥的 HS256、HS384、HS512，以及用私钥的 RS256/384/512、PS256/384/512 和 ES256/384/512，私钥可以是 PKCS#8 的 PEM 块或私有 JWK。它也能生成 `alg: none` 的未加保护令牌，并明确标注它什么也证明不了——因为要测试你的验证器是否会拒绝它，你得先有一个。
为什么它拒绝我的短密钥？
RFC 7518 要求 HMAC 密钥至少与哈希等长：HS256 需要 32 字节，HS384 需要 48 字节，HS512 需要 64 字节。浏览器用四个字符的密钥也照签不误，而得到的令牌在离线状态下几秒钟就能被破解。编码器默认拦下这种情况，同时允许你覆盖，因为复现一个弱令牌有时正是你要做的事。
它会覆盖我头部里写的算法吗？
会，`alg` 始终按你选定的算法写入，这是刻意为之。头部声称一种算法、签名却由另一种算法生成，这不是令牌，而是 JWT 最著名漏洞的起点。你写的其他头部字段——`kid`、`cty` 或任何自定义字段——都会原样保留。