SHA256
—推荐：GitHub Webhook、AWS Signature V4、Stripe 等主流服务使用
HMAC 签名
HMAC-SHA256 / SHA-1 / MD5，密钥支持 HEX 与 Base64
0 字节
密钥只在你的浏览器内存中参与计算，页面不会把它发送到任何地方。但仍建议用测试密钥试跑， 不要在生产环境粘贴长期有效的真实密钥。
待签名的消息
通常是要签名的请求体、查询串或时间戳
0 字符
签名结果
填写密钥与消息后自动计算SHA1
—旧系统兼容：部分早期 API 与 OAuth 1.0 仍在使用
MD5
—旧系统兼容：已不推荐用于新系统
关于HMAC 签名
HMAC（RFC 2104）用密钥对消息做一次带密钥的哈希，用来验证消息的完整性与来源，是 Webhook 验签、API 请求签名、JWT HS256 签名的基础。与普通哈希不同，没有密钥就无法伪造签名，因此密钥必须保密。
本工具的 HMAC-SHA256 / SHA-1 / MD5 全部基于项目内的纯 JavaScript 哈希实现，不依赖 Web Crypto，因此在 http:// 这类非安全上下文（crypto.subtle 不可用）下同样能算；密钥支持文本、十六进制与 Base64 三种输入方式，一次给出 HEX 与 Base64 两种签名结果。
常见问题
密钥只在本地参与计算吗？
是。密钥只存在于浏览器内存中，页面不发送任何包含密钥的请求。不过仍建议用测试密钥试跑——长期有效的生产密钥不应粘贴到任何在线页面，这是基本的安全习惯。
为什么我的签名和服务端算出来的不一样？
按顺序检查三件事：一是密钥的编码方式（同样是 "abc"，按文本、十六进制还是 Base64 解释完全不同）；二是待签名串是否与服务端完全一致，包括参数顺序、空格与换行；三是算法是否一致（HS256 对应 HMAC-SHA256）。这三处任意一处不同，签名就会完全不同。
HMAC 和普通哈希有什么区别？
普通哈希任何人都能算，因此无法证明消息来自谁；HMAC 混入了只有双方知道的密钥，攻击者不知道密钥就无法伪造。所以校验文件完整性用普通哈希，校验请求来源用 HMAC。