HMAC (Hash-based Message Authentication Code) 是一种结合密钥与哈希算法的消息认证码标准。它在 RFC 2104 中定义，通过两次带密钥的哈希运算，同时保证消息的完整性与发送者的身份真实性，是 API 签名、Webhook 校验、JWT、AWS Signature v4 等众多安全机制的基石。
HMAC 是由 IBM 的 Hugo Krawczyk 在 1996 年提出的消息认证码构造方法，1997 年发布为 RFC 2104。它不是一种新的哈希函数，而是一个"包装器"：在任意标准哈希函数（如 SHA-256、SHA-512、SHA-3）之上，通过对密钥进行两次异或填充（ipad 为 0x36、opad 为 0x5C），并对消息进行两层带密钥的哈希运算，最终生成一个固定长度的"消息认证码"。
这一设计并非凭空而来：早期的简单方案（如 H(key || message)）存在长度扩展攻击等风险，HMAC 则在数学上被证明在其底层哈希函数安全的前提下，能够抵御这类攻击。
与 普通 SHA 哈希 相比，两者最核心的区别在于"密钥"：任何人只要拿到同一份数据，都能计算出相同的 SHA 值，因此 SHA 只能证明"数据没有被改动"；而 HMAC 必须持有预先约定的密钥才能生成和验证，因此它同时证明了"数据没有被改动"和"数据一定来自持有密钥的一方"。在 API 调用、Webhook、支付回调等真实场景中，这两层保护缺一不可。
本工具支持 7 种最常用的哈希算法组合：HMAC-SHA1、HMAC-SHA256、HMAC-SHA384、HMAC-SHA512、HMAC-SHA3-256、HMAC-SHA3-512、以及向后兼容的 HMAC-MD5。
其中 HMAC-SHA256 是业界事实上的默认选择：它是 JWT 中 HS256 算法的底层，也是 AWS Signature v4、GitHub Webhook、Stripe 签名、Slack Events API、钉钉回调签名等众多服务的标准签名算法。HMAC-SHA512 则提供更长的摘要与更高的安全余量，适合对密码学强度有更高要求的内部系统。HMAC-SHA1 与 HMAC-MD5 主要用于与遗留系统的兼容性。
无论您选择哪种算法，工具都会同时输出 十六进制小写（默认，对应大多数编程语言的 hexdigest）、十六进制大写（常见于 Java 与部分 .NET 接口）、以及 Base64（常用于 JWT、OAuth 与 HTTP 签名头）。一次输入即可获得全部三种表示，在联调与排障时特别方便。
本工具基于浏览器内置的 Web Crypto API 与成熟的 CryptoJS 实现。全部计算完全发生在您的浏览器内：密钥、消息、结果都不会通过 HTTP 请求上传至任何服务器，也不会写入 localStorage 或 Cookie。这一点在处理生产 API Secret、支付密钥等敏感信息时至关重要——不要把密钥交给任何会"上传到云端计算"的工具。
除了本地计算外，工具还提供了完整的开发便利：随机密钥生成（一键生成 32 字节的测试密钥）、粘贴消息（从剪贴板直接读取待签名内容）、单独复制单项结果（每一种格式都可独立复制）、整体下载为 TXT（保存本次全部算法结果供文档留存）。在进行 API 联调、Webhook 回调比对、JWT 手动验证、与服务端签名差异排查等场景中，这些小功能可以显著缩短调试时间。
如果您希望了解更多关于 HMAC 的原理、7 个真实应用场景、与普通 SHA 以及 JWT 的区别，以及 6 个实用排障技巧，可以在 HMAC-SHA 算法指南 中阅读完整的技术说明。