免费JWT生成器
使用自定义头部和负载创建JSON Web Token。在您的浏览器中用HMAC-SHA256签名 · 任何数据都不会离开您的设备。
已生成的令牌
JWT 实际上是什么
JSON Web Token（JWT），读作「jot」，是一种紧凑、URL 安全的、用于在两方之间传递断言的表示形式。其格式是三段 Base64url 编码的内容，由点分隔：header.payload.signature。header 声明令牌类型（始终为 JWT）和签名算法（常用 HS256、RS256 或 ES256）。payload 承载断言，一个 JSON 对象，含 iss（签发者）、sub（主体）、aud（受众）、exp（以 Unix 时间戳表示的过期时间）、nbf（生效时间）、iat（签发时间）、jti（JWT 标识）等标准字段，以及签发者希望加入的任何应用专有断言。signature 是 header 与 payload 未被篡改的密码学证明，通过用 header 中声明的算法和密钥对拼接后的 base64url(header).base64url(payload) 字符串签名得到。JWT 由 Michael B. Jones、John Bradley 和 Nat Sakimura 于 2015 年 5 月作为 RFC 7519 制定，建立在 JOSE（JSON Object Signing and Encryption，RFC 7515 至 7520）的早前工作之上。该格式已成为现代 Web 身份验证中的主导令牌形式，被 OAuth 2.0 / OIDC 实现、API 网关、单页应用会话令牌、微服务到微服务身份验证以及大规模浏览器 cookie 会话管理所使用。
签名算法的选择，HS256 与 RS256 与 ES256
JWT 支持在 JOSE 算法注册表（RFC 7518）中登记的多种签名算法。HS256（HMAC-SHA256）最简单：一种对称算法，签名和验证使用同一个密钥。计算便宜、易于实现，并适合签名方与验证方为同一方的场景（例如，单个应用为自身签发会话令牌）。RS256（RSA-SHA256）是非对称的：私钥签名，公钥验证。用于签发者与验证者是不同方的场景，Auth0、Okta、Google Identity Platform、Microsoft Entra ID 以及大多数云身份提供商签发 RS256 签名的 JWT，因为客户端可以使用公开的 JWKS（JSON Web Key Set）端点验证签名，而无需共享密钥。ES256（ECDSA P-256 SHA-256）是 RS256 的椭圆曲线等价物，同样的公钥/私钥模型，密钥短得多（256 位对比 RSA 的 2048 位下限），验证更快。EdDSA（Ed25519）是 ES256 的现代继任者，略快且具有更干净的密码学性质；较新的 JWT 库已支持，但尚未普及。none 是 JWT 规范允许的「无签名」模式，曾在多个库中因实现未能拒绝 alg: none 令牌而引发安全事件，教训是 JWT 验证方必须显式检查算法与预期匹配。本生成器使用 HS256，因为它只需要共享密钥而不需要密钥生成；若要在生产中使用非对称算法，服务端的库才是合适的工具。
你需要手工生成 JWT 的场景
- 测试 API 端点。某 API 在 Authorization 头中要求 JWT，要用 curl、Postman 或 HTTPie 手动测试，你需要一个令牌。生成形状正确的测试 JWT，用 API 的共享密钥（在开发环境中）签名它，然后使用结果。
- 复现一个与令牌相关的 Bug。有用户报告了一个身份验证问题。重建他本应收到的、带有他自己断言的令牌，检查签名，对照已知良好和已知错误的令牌验证你服务的验证逻辑。
- 没有 auth 提供商时的本地开发。你正基于一个期望 JWT 身份验证的 API 构建前端，但还没有访问生产身份提供商。为开发生成带有合理断言的测试 JWT。
- 学习 JWT 格式。解码一个 JWT，修改一个断言，重新签名，看你的应用如何反应。动手摆弄式调试是大多数开发者最终理解 JWT 结构的方式。
- 内部服务到服务的令牌。两个内部微服务共享一个密钥，并使用 JWT 来认证请求。共享密钥的 HS256 模型在这里很合适；本工具可以为测试手动生成令牌。
安全陷阱，JWT 出错的地方
JWT 有一段长长的实现错误史，它们造成了真实的安全事件。「alg: none」攻击：早期的 JWT 库会接受算法字段被设为「none」（无签名）的令牌，让攻击者能伪造任意令牌。验证方必须显式强制要求预期的算法。算法混淆：同时接受 RS256 和 HS256 的验证方，可被以将公开的 RSA 公钥用作 HMAC 密钥的方式欺骗，攻击者用公钥以 HS256 签名，验证方用 HMAC 用同一个公钥（错）验证。验证方必须钉死预期的算法。payload 中的敏感数据：JWT 断言是 Base64 编码的，但没有加密。持有令牌的任何人都能读取每一个断言。永远不要把密码、完整信用卡号或其他机密放进 payload。没有过期：没有 exp 断言的 JWT 永久有效。务必设置合理的过期（访问令牌取分钟级，刷新令牌取天级）。无法撤销：JWT 是自包含的，一旦签发，就在 exp 之前一直有效，与用户登出、改密、被封停无关。要么接受这一限制，要么维护一个撤销列表（这部分抵消了无状态令牌的意义），要么使用短寿命的访问令牌配合刷新令牌轮换。localStorage vs cookie 中存放：localStorage 中的 JWT 对页面上的任何 JavaScript 都可访问（XSS 风险）；HttpOnly cookie 中的 JWT 则不可（但会随跨域请求自动发送，CSRF 风险）。两者各有取舍；现代最佳实践倾向于 HttpOnly cookie 加 SameSite 限制再加 CSRF 令牌。
JWT 与会话 cookie 与 PASETO
JWT 不是唯一选择。传统会话 cookie 存放一个不透明的会话 ID；服务器把真正的会话状态保存在数据库或缓存中。优点：撤销极易（删除服务端记录）、无断言数据外泄风险、无签名复杂度。缺点：每次请求都需要查询会话存储（延迟）、跨服务难以扩展。PASETO（Platform-Agnostic Security Tokens，Scott Arciszewski 2018）是 JWT 的替代品，旨在避免算法混淆与「none」陷阱，版本化格式、不进行算法协商、强制签名、密码套件选择受限。PASETO 在安全敏感领域已有进展，但在更广阔的生态中并未取代 JWT。Macaroons（Google，2014）是一种更灵活的令牌格式，支持链式能力限制，但 2026 年基本仍是研究主题。OAuth 2.1 整合了OAuth 2.0 的最佳实践，JWT 仍是典型的访问令牌格式。2026 年的务实选择仍然是：无状态微服务和 API 令牌用 JWT，传统服务端渲染 Web 应用用不透明会话 cookie，希望默认更强的全新项目用 PASETO 作为现代替代。
常见问题
我可以在没有密钥的情况下解码JWT吗？
可以。JWT的头部和负载部分仅使用Base64url编码，并未加密。您可以在没有密钥的情况下读取所有声明。密钥仅用于验证签名是否有效（即令牌未被篡改）。
在此粘贴生产环境JWT安全吗？
安全。此工具完全在您的浏览器中运行 ， 不会向任何服务器发送数据。您的令牌和密钥仅在本地JavaScript环境中处理，绝不会被记录或传输。
HS256、RS256和ES256有什么区别？
HS256使用共享的HMAC密钥（对称）。RS256和ES256使用公钥/私钥对（非对称） ， 私钥签名令牌，公钥验证令牌。此工具支持HMAC算法；对于RS256/ES256验证，请使用服务器端库。