HMAC-SHA-1 Generator

About HMAC Generator

An HMAC proves two things at once: that a message has not been altered, and that whoever produced the code holds the shared secret. It is what webhook signatures are, what API request signing is built on, and what a plain hash cannot do.

The secret can be given as text, or as the raw bytes a provider hands you written in hex or Base64 — getting that wrong is the usual reason a signature will not verify. The hash underneath can be any of the SHA-2, SHA-3, BLAKE2 or legacy algorithms, and the code comes back in hex, Base64 or Base64url.

Paste the signature you received into *Verify signature* and it says valid or invalid outright, comparing in constant time and ignoring the sha256= prefix that GitHub, Stripe and others put in front of theirs.

The secret is used here and never sent anywhere — but it is still a secret, so use a test key when you are only exploring.

Where it helps

• Proves both integrity and origin, which a plain hash cannot.
• SHA-256, SHA-384, SHA-512 and SHA-1 cover every common webhook scheme.
• Hex or Base64 output to match the provider's encoding.
• The key stays in your browser — it is never sent over the network.

Limits

• Security rests entirely on the secret: anyone holding it can forge a valid code.
• The message must be byte-identical to what the sender signed — a re-serialised JSON body will not match.
• Comparison in your own code must be constant time; a naive === leaks timing information.
• It authenticates, it does not hide anything. The payload remains readable.

Frequently asked questions

Why does my computed signature never match the webhook header?

Sign the raw request body exactly as received, before any JSON parsing or re-serialising. Many schemes also prefix a timestamp — check the provider's exact signing string.

HMAC or a plain hash?

HMAC whenever a third party could tamper with the message. A hash proves nothing about who produced it.

Is HMAC-SHA1 still safe?

HMAC-SHA1 has held up better than plain SHA-1, and some APIs still require it, but choose SHA-256 for anything new.

How long should the secret be?

At least as long as the digest — 32 random bytes for SHA-256. Generate it with the Random String or Password tool, not by hand.

Related tools

• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• JWT — Read, verify and sign JSON Web Tokens
• Text Encryption — AES-256-GCM with a PBKDF2 passphrase
• Random String — Random identifiers from a chosen alphabet
• MD5 Generator — MD5 digests, with a plain account of what they are still good for
• Key Derivation — Stretch a passphrase into key material with PBKDF2, scrypt or Argon2id

More Security & Cryptography tools

• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• MD5 Generator — MD5 digests, with a plain account of what they are still good for
• HMAC Generator — Keyed message authentication codes
• Key Derivation — Stretch a passphrase into key material with PBKDF2, scrypt or Argon2id
• Password Generator — Strong random passwords with an entropy estimate
• Password Strength — Judge a password by what an attacker would actually try
• JWK Generator — A JSON Web Key for a JOSE algorithm, with its key set and thumbprint id
• Key Pair Generator — RSA and elliptic-curve key pairs, generated in this tab and never sent
• TOTP / HOTP Generator — Two-factor codes, the QR code to enrol with, and why one did not match
• Text Encryption — AES-256-GCM with a PBKDF2 passphrase
• Bcrypt Generator — Hash a password with bcrypt, verify one against a hash, or read what a hash is made of