JWT 解码器
解码 JSON Web Tokens 以查看 Header 和 Payload。
什么是 JSON Web Token (JWT)？为什么需要解码器？
JSON Web Token (JWT) 是一种紧凑且 URL 安全的方式，用于在各方之间传输声明（Claims）。JWT 中的声明被编码为 JSON 对象，用作 JSON Web 签名 (JWS) 结构的有效负载，或作为 JSON Web 加密 (JWE) 结构的明文，从而使声明能够被数字签名、受消息认证码 (MAC) 保護或被加密。
一个 JWT 通常由三部分组成，用点号 (.) 分隔：Header（头部）、Payload（负载）和 Signature（签名）。Header 定义了用于签名的算法（如 HS256 或 RS256）。Payload 包含传输的实际数据（如用户 ID、权限等）。Signature 确保令牌未被篡改。由于 JWT 仅经过 Base64Url 编码，并未默认加密，因此任何能看到令牌的人都能看到其中的数据。这就是为什么在开发过程中 JWT 解码器至关重要：它允许工程师快速检查令牌内容，以验证是否传输了正确的用户信息、过期日期和授权角色。ProUtil 的 JWT 解码器提供了一个安全的客户端环境进行检查，毫无敏感数据泄露风险。
如何检查和调试 JSON Web Tokens
获取令牌：从您的授权标头或浏览器存储中复制完整的 JWT 字符串。
输入令牌：将编码后的字符串粘贴到“已编码的令牌”字段中。我们的 UI 经过优化，支持处理长字符串。
即时头部分析：查看 Header 部分，识别签名算法（如 HS256 或 RS256）和令牌类型。
查看有效负载：检查解码后的 Payload。在这里您可以验证用户属性、签发者 (iss)、受众 (aud) 和自定义声明。
检查过期时间 (exp)：定位 payload 中的 “exp” 声明，以确定令牌是否仍然有效或已过期。
理解签名结构：虽然这只是一个解码器，但识别签名部分（第三段）有助于您验证令牌的完整性结构。
提升可读性：使用格式化后的 JSON 视图，使复杂的嵌套声明易于阅读和审计。
保护敏感数据：切勿在 JWT 的 Payload 中放置密码或敏感密钥，因为它们可以被此类工具轻松解码。
识别令牌错误：如果令牌被截断或格式错误，我们的工具会在错误面板中提供即时反馈。
隐私优先调试：使用“复制”按钮安全地将部分解码数据移动到您的本地文档或调试日志中。
面向工程师的高级 JWT 审查功能
JWT 解码示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoyMDI2fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"sub": "1234567890",
"name": "John Doe",
"iat": 2026
}理解 JWT 安全与实现错误
格式错误的令牌
有效的 JWT 必须包含两个点号 (.) 将三个部分分隔开。如果不符合此结构，则不是标准 JWT。
Base64Url 填充错误
JWT 通常省略 “=” 填充。如果您手动添加或令牌被截断，解码过程可能会失败。
敏感数据泄露
在 Payload 中放置个人隐私 (PII) 或密码是巨大的安全风险，因为 Payload 只是被编码而非加密。
过期时间声明 (exp)
始终检查过期日期。过期的令牌会导致应用中出现 “401 Unauthorized” 错误。
算法混淆
确保 “alg” 头部与服务器预期的算法匹配，以防止算法替换攻击。
None 算法漏洞
警惕 algorithm 被设置为 “none” 的令牌。现代系统应直接拒绝此类令牌。
专家洞见：关于 JWT 的常见问题
Q.在线解码我的 JWT 安全吗？
使用 ProUtil 是安全的。我们的解码器完全在您的浏览器中使用客户端 JavaScript 运行。您的令牌永远不会发送到我们的服务器或任何第三方。
Q.HS256 和 RS256 有什么区别？
HS256（使用 SHA-256 的 HMAC）是对称算法，使用同一个密钥进行签名和验证。RS256（使用 SHA-256 的 RSA 签名）是非对称算法，使用私钥签名，公钥验证，对分布式系统更安全。
Q.我可以修改 JWT 中的数据并重新签名吗？
您可以解码并修改负载，但这样做会使 Signature 失效。要重新签名，需要拥有签发者的原始密钥。这防止了未经授权的篡改。
Q.JWT 是加密的吗？
默认不加密。标准的 JWS 令牌仅经过 Base64Url 编码和签名。任何人都能解码负载。如果需要隐藏数据，必须使用 JWE（JSON Web 加密）。
Q.为什么 JWT 使用 Base64Url 而非标准 Base64？
Base64Url 用 `-` 和 `_` 替换了 `+` 和 `/` 并去除了填充 (`=`)，使其能安全地在 URL 中使用而无需额外编码。
Q.JWT 中绝对不能存储什么？
切勿在 JWT 中存储敏感信息，如密码、信用卡号。因为负载部分仅是编码形式，任何拿到令牌的人都能读取。
Q.如何处理 JWT 过期？
负载中的 `exp` 声明指明了过期时间。应用应验证该声明并拒绝过期令牌。“刷新令牌 (Refresh Token)” 是管理会话续期的标准方式。
Q.JWT 中的 “Claim（声明）” 是什么？
声明是关于主体的信息。标准声明包括 `sub`（主体）、`iss`（签发者）、`exp`（过期时间）。您也可以添加自定义声明。
Q.较大的 JWT 负载会影响性能吗？
会。由于 JWT 常随 HTTP 请求发送，较大的负载会增加网络开销。请保持令牌精简，仅包含必要数据。
Q.JWT 可以被撤销吗？
JWT 是无状态的，意味着在过期前一直有效。要在过期前撤销，需要在服务器端维护“黑名单”，这在一定程度上削弱了无状态的优势。
Q.JWT 应存放在 LocalStorage 还是 Cookie 中？
LocalStorage 易用但易受 XSS 攻击。HttpOnly 和 Secure 的 Cookie 对 XSS 抵御能力更强，但需注意 CSRF 攻击。
Q.忘记校验 JWT 签名会怎样？
如果不校验签名，攻击者可以伪造包含恶意声明（如 `admin: true`）的令牌，而您的系统会信任它。签名校验是 JWT 安全中最关键的一步。
Q.JWT 头部中的 “kid” 是什么？
Key ID 的缩写，用于指明使用哪个密钥进行签名。这在密钥轮换或使用多个公钥 (JWKS) 时非常有用。
Q.JWT 大小有限制吗？
规范虽无限制，但大多数服务器对头部大小有限制（通常约 8KB 或 16KB）。如果 JWT 超过此限制，请求将失败。
Q.为什么显示签名 “Invalid”？
可能因为令牌被篡改、使用了错误的校验密钥，或者在传输过程中出现了数据损坏。
Q.ProUtil 的 JWT 解码器开源吗？
是的！ProUtil 是开源工具集。您可以在 GitHub 上查看代码以核实我们的隐私声明。