JWT签名验证工具 - 在线校验JWT Signature是否有效（HS/RS/ES）

签名验证是 JWT 唯一可信的根基#

前面反复强调过一句：解析不等于验证。JWT 的 Header 和 Payload 任何人都能解开看，真正让 Token”可信”的是 Signature。只有当签名能被正确校验通过，你才能确认：内容没有被篡改，且它确实由持有对应密钥的一方签发。

星点 JWT 签名验证要做的就是这个判断：输入 Token 与 Secret（或 Public Key），按 HS256/384/512、RS256/384/512、ES256/384/512 校验签名是否有效，结果明确区分”验证通过 / 验证失败 / 算法不支持 / 密钥格式错误 / Token 格式错误”。密钥仅在浏览器本地参与计算，不上传、不保存。

验证是怎么工作的#

工具读取 Token 头部声明的 alg 算法；
用你提供的密钥对 Header.Payload 重新计算签名；
与 Token 里的 Signature 比对；
给出明确结论。

这也解释了为什么”验证”和”解析”是两件事：解析只需要解码，验证需要密钥 + 密码学计算。没提供正确密钥，任何工具都无法证明签名有效。

HMAC 与 RSA/ECDSA 验证的差异#

家族	算法	验证输入	为什么
HMAC	HS256 / HS384 / HS512	Secret	对称算法，签发与验证同一把密钥
RSA	RS256 / RS384 / RS512	Public Key	私钥签名、公钥验证
ECDSA	ES256 / ES384 / ES512	Public Key	私钥签名、公钥验证

工具按 Token 头部 alg 自动选择验证方式，你只需要提供正确的密钥。

怎么用（详细步骤）#

打开 JWT 签名验证；
粘贴需要验证的 JWT；
根据算法输入 Secret（HMAC）或 Public Key（RSA/ECDSA）；
点击”验证签名”；
查看结果：验证通过或失败，以及失败的具体原因。

结果分类详解#

结果	含义
验证通过	签名与所提供密钥匹配
验证失败	密钥不正确、Token 被篡改、或算法与密钥不匹配
算法不支持	Header 声明的 `alg` 不在支持范围内
密钥格式错误	提供的密钥不是有效 PEM / 格式不符
Token 格式错误	结构不完整或无法解析

把失败原因分类，是为了让你更快定位问题——是抄错密钥，还是 Token 本身被人改过。工具会尽量给出具体分类。

验证失败，通常是什么原因#

现象	可能原因	处理
密钥错误	Secret 或 Public Key 抄错	核对密钥来源
Token 被篡改	Payload 或 Header 被修改	用 JWT 在线解析对比内容
算法不匹配	用 HS 的 Secret 去验 RS 的 Token	检查 Header 的 `alg`
密钥格式错误	PEM 缺头尾、或格式不对	用 PKCS#8/SPKI 标准 PEM

关于 RSA/ECDSA 公钥格式#

验证 RSA/ECDSA 只需公钥（PEM，PKCS#8/SPKI 格式）。私钥用于签名生成，不应出现在验证环节——把私钥贴到验证工具里既没有必要，也有泄露风险。

如果你手头只有私钥、需要从私钥导出公钥，请用本地的 openssl 等工具完成，不要为了图方便把私钥发给任何在线服务。

验证通过就万事大吉了吗#

不是。 签名验证通过只代表”内容未被篡改、由持有密钥方签发”。实际业务还要结合：

过期时间 exp：是否已经过期（用 JWT 在线解析判断）；
issuer iss / audience aud：签发方与接收方是否符合约定。

签名只是 JWT 信任链里的第一步，不是全部。

警惕算法混淆攻击#

如果后端不严格限制允许的算法，攻击者可能把 alg 从 RS256 改成 HS256，并用公钥当作 HMAC Secret 来伪造签名。这类”算法混淆”是真实存在的安全问题。验证时务必核对 Token 头部声明的算法是否符合预期，而不是盲目信任 alg 字段。

签名验证到底防住了什么#

签名验证通过，能证明三件事：

完整性：Header、Payload 自签发后没有被改动过——哪怕改一个字符，签名都会对不上；
来源：Token 确实由持有对应密钥（私钥或 Secret）的一方签发；
可追溯：结合 kid 等字段，能定位用哪把密钥签的。

它不能证明的是：Token 是否已过期、签发方是否可信、权限是否足够。这些要靠 exp / iss / aud 等 Claims 与业务逻辑另行判断。所以验证通过只是信任链的一环，不是终点。

三个常见的安全陷阱#

陷阱	说明	应对
`alg: none`	无签名算法，任何人都能伪造	拒绝 `none`，强制指定允许的算法
算法混淆	把 `RS256` 改成 `HS256`，用公钥当 Secret 伪造	后端严格限定每个 Token 允许的算法
弱密钥	HS256 用了可预测的 Secret	使用足够长的随机密钥

验证工具帮你把”这个 Token 签名对不对”这件事判断清楚，但算法层面的安全策略，仍要在你自己的服务端严格实施。本工具只做正常签名验证，不提供破解、爆破、弱密钥扫描或绕过能力。

常见问题（FAQ）#

为什么验证失败？

常见原因：密钥不正确、密钥格式错误、Token 被篡改（Payload 或 Header 被修改）、算法与密钥不匹配。工具会尽量给出具体分类。

验证通过代表什么？

代表该 Token 的签名与所提供密钥匹配，即内容未被篡改且由持有该密钥的一方签发。仍建议结合实际业务（过期时间、issuer、audience）综合判断。

这里会帮我破解或爆破密钥吗？

不会。本工具只做正常签名验证，不提供任何破解、爆破、弱密钥扫描或绕过能力。

RSA / ECDSA 需要公钥还是私钥？

验证只需公钥（PEM，PKCS#8/SPKI）。私钥用于签名生成，不应出现在验证环节。

怎么生成一个 Token 来测试验证？

用 [JWT 生成器](https://www.xingdian.net/app/jwt/generate/) 生成带签名的 Token，再用本工具验证；快速测试用 [JWT 测试 Token 生成器](https://www.xingdian.net/app/jwt/testtoken/)。

验证的密钥会上传吗？

不会。密钥仅在浏览器本地参与计算，不上传、不保存。

和解析器有什么区别？

解析器只解码内容看结构；本工具才真正校验签名。两者配合：先用 [JWT 在线解析](https://www.xingdian.net/app/jwt/parse/) 看内容，再用本工具验真伪。

ES256 和 RS256 验证有什么区别？

都是非对称算法、都用公钥验证，区别在于底层曲线：RS 基于 RSA，ES 基于椭圆曲线。工具按 Token 头部 `alg` 自动选择对应验证方式。

什么情况会出现"算法不支持"？

当 Token 头部声明的 `alg` 不在 HS256/384/512、RS256/384/512、ES256/384/512 这 9 种内（例如声明了 `none` 或其它值），会提示"算法不支持"。

总结#

JWT 签名验证是判断 Token 是否可信的唯一手段：用 Token 声明的算法 + 正确密钥重新校验签名。它和解析是两回事——解析看内容，验证判真伪。把 JWT 在线解析和本工具配合使用，才能既读懂又验清一个 Token。

立即体验：访问 JWT 签名验证