HMAC 计算HMAC Generator
输入密钥与消息实时计算 HMAC 签名，支持 MD5 / SHA-1 / SHA-256 / SHA-512，大小写 Hex 与 Base64 三种格式逐行复制，UTF-8 中文不乱码，与 openssl / Python hmac / Java 结果一致。调试接口签名、验签 Webhook 回调更快。密钥全程不上传。
Base64 为原始摘要字节的编码形式，与十六进制内容等价，常见于 HTTP 头等二进制签名字段场景。
工具介绍
3 段详细说明HMAC 计算是面向开发者与普通用户的一站式 HMAC 签名工具。输入密钥与消息，立即得到 HMAC-MD5 / SHA-1 / SHA-256 / SHA-512 标准签名，并同时给出大写 Hex 与 Base64 变体，逐行一键复制，调试接口签名、核对回调验签、复现云厂商签名算法更快。
算法基于 RFC 2104 纯前端实现，完整兼容 UTF-8，密钥与消息中的中文、emoji 均按字节正确编码，与 OpenSSL openssl dgst -sha256 -hmac "key"、Python hmac.new、Java Mac 等主流实现结果完全一致。
所有计算都在浏览器内存中完成，密钥与消息不上传任何服务器。支持边输入边实时出结果、⌘+↵ 快捷键执行、断网可用，适合核对 Webhook 回调、复现支付验签、排查签名不一致等高频场景。
基础知识 · HMAC 签名
RFC 2104 · 4 种算法HMAC（Hash-based Message Authentication Code）是基于哈希的消息认证码。理解以下 6 个要点，就能正确、安全地使用它：
keyed-hash带密钥的哈希rfc 2104标准构造公式HMAC(K,m) = H((K′⊕opad) ‖ H((K′⊕ipad) ‖ m))。两次哈希、两个固定填充常量（ipad=0x36、opad=0x5c），结构简单且经过了近 30 年的密码学检验。block-size分组大小与长密钥avalanche雪崩效应hmac("key1","msg") 与 hmac("key2","msg") 的结果完全不同且无规律，签错密钥一眼就能发现。length-extension免疫长度扩展攻击H(secret ‖ message) 存在长度扩展攻击：知道哈希值可追加内容继续算。HMAC 的双层结构天然免疫此类攻击，这也是它被发明的初衷之一。algo-choice算法怎么选≥32 字节 随机数据（可用随机密码工具生成），不要用用户名、日期等可猜测内容，更不要硬编码在前端代码里。hmac.compareDigest（Python）/ crypto.timingSafeEqual（Node）等恒时比较，避免逐字符 == 比较引入时序侧信道。echo -n "msg" | openssl dgst -sha256 -hmac "key"，注意 -n 去掉行尾换行，否则签名不同（多算了一个 \n 字节）。保密传输 请配合 TLS 与 AES 等对称加密；口令存储 必须用慢哈希。使用说明
4 步快速入门使用场景
5 个真实案例GitHub / 微信支付 / Stripe 等回调带 HMAC 签名头，本地复算比对确认请求真实未被篡改。
云厂商 OpenAPI 常用 HMAC-SHA256 对参数签名，复现拼接与签名规则，排查验签失败。
前后端约定 HMAC 签名鉴权时，双方各自计算比对，快速定位密钥、编码或参数顺序差异。
对传输内容附带 HMAC 签名，接收方用共享密钥验证，比裸哈希更防篡改与伪造。
以会话标识为消息派生校验值，防止 Cookie / URL Token 被伪造或篡改。
常见问题
10 个问答HMAC 是什么？和普通哈希有什么区别？
HMAC（Hash-based Message Authentication Code，RFC 2104）是带密钥的哈希：HMAC(K, m) = H((K′⊕opad)‖H((K′⊕ipad)‖m))。普通哈希任何人都能算，HMAC 只有持有密钥的一方才能算出与验证，因此能同时提供完整性校验与身份认证。
HMAC 能解密吗？
不能。HMAC 是单向哈希构造，数学上不可逆，也不是加密。它的作用是「证明消息出自持钥者且未被篡改」，需要保密传输时应配合 AES 等对称加密使用。
我的密钥和消息会上传到服务器吗？
不会。HMAC 计算完全在浏览器内存中完成，密钥与消息不上传任何服务器。可断网使用，关闭网络后再打开仍能正常使用。
HMAC-MD5 / SHA-1 还能用吗？
HMAC 的构造方式削弱了底层哈希碰撞缺陷的影响，HMAC-MD5 / HMAC-SHA-1 目前没有实用的伪造攻击，老系统兼容仍在使用。但新项目应首选 HMAC-SHA-256 或 HMAC-SHA-512。
结果和 openssl / Python hmac 一致吗？
一致。本工具严格按 RFC 2104 实现，UTF-8 编码下与 openssl dgst -<alg> -hmac、Python hmac.new(key, msg, hashlib.<alg>).hexdigest()、Java Mac 等主流实现完全相同，可放心互验。
为什么同样的密钥和消息，算出来的签名和别人不一样？
常见原因：① 对方按 GBK 等非 UTF-8 编码；② 消息拼接规则不同（参数顺序、分隔符、是否含换行）；③ 密钥处理不同（有的系统先对密钥做一次哈希再用）；④ 十六进制大小写或 Base64 显示差异。请逐项核对。
密钥为空可以计算吗？
可以。RFC 2104 允许空密钥，此时按全 0 补齐分组长度参与运算，与 openssl 传空密钥的行为一致。但生产环境务必使用足够长的随机密钥。
密钥太长或太短有影响吗？
太长：超过分组大小（MD5 / SHA-1 / SHA-256 为 64 字节，SHA-512 为 128 字节）时会先对密钥哈希一次再补齐，结果仍符合标准。太短：会补 0 到分组长度，建议密钥不少于 32 字节随机数据。
Base64 格式是什么？哪里会用到？
Base64 是原始摘要字节（而非十六进制字符串）的编码形式，与 Hex 内容等价、只是编码不同。部分回调验签字段（如 HTTP 头中的二进制签名）使用该格式。
HMAC 能用来存密码吗？
不建议直接存。HMAC 计算依旧很快，挡不住对密钥的暴力猜测。口令存储应使用每用户随机盐 + 慢哈希（bcrypt / scrypt / argon2）；HMAC 适合做消息认证与接口签名。
相关工具
编码加密分类数据来源
隐私优先RFC 2104 纯 TypeScript 实现，零第三方依赖、无 WASM。哈希核心复用本站 MD5（RFC 1321）与 SHA 系列（FIPS 180-4）实现，密钥与消息经 TextEncoder 按 UTF-8 编码后逐字节计算，中文 / emoji 不乱码，与 openssl、Python hmac、Java Mac 等主流实现结果一致。