HMAC-SHA1/256/384/512 —— 消息 + 密钥，输出 hex 与 base64，密钥可按 UTF-8/hex/base64 解读 —— 100% 浏览器本地
- 本地处理
- 分类 编码加密
- 适合 快速检查小 payload、令牌、哈希和编码值。
——这个工具能做什么
免费在线 HMAC 生成工具。粘贴要签名的原始消息,填入密钥,选 HMAC-SHA1 / HMAC-SHA256 / HMAC-SHA384 / HMAC-SHA512,即可同时 得到小写 hex 和标准 base64 两种形式的签名 —— 这正是各家 webhook 和 API 文档里实际粘贴的两种写法。签名全程通过浏览器原生 WebCrypto 的 `crypto.subtle.sign` 完成,消息和密钥不离开页面、不发往服务器、 也不被记录。
多数在线 HMAC 工具最容易踩错的一点是密钥编码。一把密钥可能是 UTF-8 文本(`whsec_...`)、可能是裸 hex(32 字节密钥写成 64 个十六 进制字符)、也可能是 base64(Stripe 风格)。同一把密钥按错误方式 解读出的字节不同,算出来的签名看着合法、其实完全不对 —— 这就是 "密钥明明没错,webhook 校验却过不了"的经典原因。本工具让你显式 选择 UTF-8 / hex / base64,并实时显示解出的密钥字节长度,方便你 确认解读方式和发送方编码方式一致。
它可以用来复现支付平台在 `X-Signature` 头里发来的签名、生成你自己 HTTP 客户端要附带的签名头、手动校验 GitHub 或 Shopify 的 webhook, 也可以单独验证 JWT HS256 里的 HMAC 步骤。HMAC 是确定性的:算法、 消息、密钥、密钥编码四者相同,签名必然相同 —— 所以一旦对不上, 就说明四者之一不同,本工具帮你定位是哪一个。
工具细节
- 输入
- 文本 + 数值
- 页面会根据工具类型展示文本框、数值控件、文件选择或结构化输入。
- 输出
- 即时结果 + 复制
- 结果区优先给出可操作结果，支持项会显示复制、下载或可视化预览。
- 隐私
- 浏览器本地处理
- 主工具逻辑未发现外部 API 调用，输入通常留在当前标签页内处理。
- 保存 / 分享
- 本地保存偏好
- 偏好、历史或草稿保存在本机浏览器，不需要账号。
- 性能预算
- 首屏 JS ≤ 14 KB
- 没有声明 WASM 依赖，适合快速打开和移动端使用。
- 适用场景
- 编码加密 · 程序员
- 分类和职业标签用于推荐相关工具、组织内链，并帮助用户快速判断是否适合当前任务。
怎么用
-
1. 输入
把内容粘贴或拖入工具面板。
-
2. 处理
点击按钮,在浏览器内本地处理,文件不上传。
-
3. 复制 / 下载
一键复制结果或下载到本地。
HMAC 生成器 适合怎么用
适合做浏览器本地的编码、解码、哈希、令牌检查和可分享转换。
适合编码任务
- 快速检查小 payload、令牌、哈希和编码值。
- 把值整理好再放进 API、URL、文档或客服工单。
- 输入可能敏感时,尽量避开账号型在线工具。
编码检查项
- 真实密钥不要随便粘贴,除非确认能接受本地浏览器处理。
- 分享结果前确认这个操作是否可逆。
- 哈希值要核对算法和大小写是否符合对方要求。
下一步可以接着做
这些入口会把当前任务接到更完整的工具链里。
真实使用场景
手动校验 Stripe / 支付平台的 webhook 签名
webhook 没触发你的处理逻辑,怀疑是签名校验。从日志里拿到原始 请求体,粘成消息,取 webhook 签名密钥(Stripe 的 `whsec_...` 是 UTF-8 文本),选 HMAC-SHA256,把 hex 输出和 `Stripe-Signature` 头里的 `t=...,v1=...` 比对。对得上,说明你 的校验代码有 bug(常见是重新 parse 了 JSON 改了字节);对不上, 说明密钥用错了或签错了 payload。无论哪种,你都用两次粘贴就把 问题圈定了,不用反复加打印再重新部署。
生成客户端要发的 X-Signature 头
你在对接一个要求每个请求都带 `X-Signature: <请求体的 HMAC>` 的接口。把请求体粘成消息,粘上平台给的 API key,选文档指定的 算法,把 hex(或 base64 —— 看文档)签名直接复制到 Postman 或 curl 的测试里。这样能在把签名写进代码前先确认服务端期望的确切 签名,把 HMAC 这一步单独调通,不和鉴权、路由搅在一起。
校验 JWT HS256 token 的签名段
一个 JWT 被判为"签名无效",你想确认到底是签名本身错了还是上游 出了问题。把 token 的 `header.payload`(前两段以点分隔、base64url 的内容)当消息,粘上 HS256 密钥,选 HMAC-SHA256,把 base64 输出 和 token 第三段比对(注意把 base64url 的 `-_` 换成 base64 的 `+/`)。对得上,签名没问题,问题在 claims 或过期;对不上,就是 密钥或签名输入不一致。
复现 GitHub webhook 投递用于测试
GitHub 用 HMAC 给 webhook payload 签名,发的是 `X-Hub-Signature-256: sha256=<hex>`。要在本地服务器上重放一次 投递,把确切的 JSON payload 粘成消息,把 webhook secret 当 UTF-8 密钥粘上,选 HMAC-SHA256,在 hex 输出前加 `sha256=` 还原 出这个头。这样你就能用一个服务端真的会接受的签名 curl 你的接口, 不必等 GitHub 真发一次事件。
排查 hex/base64 或密钥编码不一致
两个系统密钥一致,签名却对不上。粘上共享的消息和密钥,然后在 UTF-8、hex、base64 之间切换密钥编码,看字节长度读数:一把 32 字节随机密钥写成 64 个 hex 字符,按"hex"解出 32 字节、按"UTF-8" 却解出 64 字节,签名自然完全不同。再切换 hex 与 base64 两种 输出 —— 如果一边比 base64、一边比 hex,签名"对不上"只是因为它们 是同一段字节的不同编码。
常见踩坑
签错了字节。HMAC 算的是按原样发送的原始消息 —— 签名前你要是重新序列化了 JSON、重排了 key、或加/去了末尾换行,算出的签名就和发送方不同。永远签逐字节的 payload,别签重建出来的对象。
看错密钥编码。一把 32 字节密钥写成 64 个 hex 字符,和把这 64 字符当 UTF-8 文本,完全不是一回事 —— 解出的字节不同、签名也不同。让密钥模式(UTF-8 / hex / base64)和对方编码密钥的方式一致,并用字节长度读数确认。
拿不同的输出编码去比。hex 和 base64 是同一段签名字节的两种编码;如果你代码里把期望值做 base64 解码、却粘了 hex 形式(或反过来),比对会无缘无故失败,根本不是密码学问题。挑接收方真正用来比对的那种编码。
隐私说明
整个运算 —— 解码你的密钥(UTF-8 / hex / base64)、导入成 WebCrypto 密钥、再用 HMAC-SHA1/256/384/512 给消息签名 —— 全部在你的浏览器 标签页里通过原生 `crypto.subtle` 完成。消息和密钥不上传、不记录, 也不进任何统计。和那些把状态写进 URL 以便分享的工具不同,本工具 刻意不把消息和密钥写进 URL,也不写进 localStorage,因为签名密钥 一旦泄露,它签过的每个签名都会被攻破。本地唯一保存的只有不敏感的 界面偏好(你上次选的算法和密钥编码),让页面记住你的设置,却绝不 记住你的密钥。
常见问题
类似工具组合
做你这行的人, 还会一起用这些。