SHA-256 vs HMAC-SHA256
Both are based on SHA-256. Both produce a 256-bit digest. But one proves data integrity, and the other proves integrity plus who created it.
For context on how hashing fits alongside encryption and encoding, see the complete guide to encryption, hashing, and encoding.
- •You want to verify a file has not been corrupted
- •You need a fingerprint or checksum of content
- •Anyone should be able to compute and verify the hash
- •No shared secret is available or needed
- •You need to sign API requests with a shared secret
- •You want to verify a webhook payload came from a trusted source
- •You need to prove a message was not modified by an attacker
- •Both parties share a secret key and only they should validate
Key insight: SHA-256 proves integrity. HMAC-SHA256 proves integrity and authenticity.
What is SHA-256?
SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function that takes input of any length and produces a fixed 256-bit (32-byte) output called a digest. The function is deterministic — the same input always produces the same hash — and one-way — you cannot recover the original input from the hash.
SHA-256 requires no secret key. Anyone who has the input data can compute the same hash and compare it against a known value to verify the data has not changed. This makes it suitable for public integrity checks like file checksums, but not for authentication.
SHA-256 alone does not prove who created the data. An attacker who intercepts or modifies data can simply compute a new SHA-256 hash of the modified content and present it as valid. If integrity must be tied to a trusted source, a secret key is required — which is where HMAC comes in.
Key Points
- •Purpose: Produce a fixed-length fingerprint of data for integrity verification
- •Reversible: No — one-way function, input cannot be recovered
- •Requires secret key: No — anyone can compute it
- •Common use cases: File checksums, content deduplication, Git commit IDs, password hashing input (with a proper KDF)
What is HMAC-SHA256?
HMAC-SHA256 (Hash-based Message Authentication Code using SHA-256) combines the SHA-256 hash function with a secret key. The result is a keyed digest that can only be produced and verified by parties who share the secret. This adds authentication on top of integrity.
The HMAC construction processes the key and message in a specific way designed to be secure even if weaknesses are found in the underlying hash function. It is defined in RFC 2104 and is the basis for request signing in services like AWS Signature Version 4, GitHub webhook verification, and Stripe payment confirmations.
When you receive a message with an HMAC-SHA256 signature, you compute the HMAC yourself using the shared secret and compare it to the received value. If they match, you can be confident the message is unmodified and came from a party that knows the key.
Key Points
- •Purpose: Verify integrity and authenticate the source of a message using a shared secret
- •Reversible: No — the digest cannot be reversed to recover the message or key
- •Requires secret key: Yes — only parties with the key can produce or verify the HMAC
- •Common use cases: API request signing, webhook payload verification, session token validation, message authentication
HMAC-SHA256 is not encryption
HMAC does not hide the message. The message content remains readable. HMAC only proves the message is authentic and unmodified. If you also need confidentiality, encrypt the data separately using AES-GCM or a similar authenticated encryption scheme.
Key Differences
| Aspect | SHA-256 | HMAC-SHA256 |
|---|---|---|
| Purpose | Integrity verification | Integrity + authentication |
| Secret key required? | No | Yes |
| Provides integrity? | Yes | Yes |
| Provides authentication? | No | Yes (with shared secret) |
| Reversible? | No | No |
| Provides confidentiality? | No | No |
| Typical use cases | File checksums, fingerprints, content addressing | API signing, webhook verification, message authentication |
| Threat model addressed | Accidental corruption; public integrity checks | Active tampering by an attacker without the secret |
When Should You Use SHA-256?
- 1.Verifying the integrity of a file download — compare the published checksum against the SHA-256 of the downloaded file
- 2.Detecting accidental corruption in stored or transmitted data where no adversary is assumed
- 3.Generating content fingerprints for deduplication, caching, or content-addressed storage
- 4.Non-authenticated integrity checks where public verification is acceptable and expected
If anyone should be able to independently verify the hash without a shared secret, SHA-256 is appropriate. If the hash needs to prove who produced the data, use HMAC-SHA256.
When Should You Use HMAC-SHA256?
- 1.Signing API requests — include the HMAC in a header so the server can verify the request was not tampered with in transit
- 2.Validating webhook payloads — services like GitHub, Stripe, and Twilio sign their payloads with HMAC-SHA256 so you can confirm they are genuine
- 3.Ensuring messages between two services were not modified by anyone who does not hold the shared secret
- 4.Authenticating messages within systems where both parties share a secret key and only they should be able to produce valid signatures
HMAC protects against active tampering by an attacker who does not know the secret key. It does not protect against an attacker who has compromised the key — key management and rotation are part of a complete security posture.
Common Misconceptions
"SHA-256 is encryption"
SHA-256 is a hash function, not encryption. It is one-way and uses no key. You cannot decrypt a SHA-256 hash to recover the original data. For encryption, use AES.
"HMAC hides the message"
HMAC does not encrypt anything. The message is transmitted in plaintext alongside the HMAC signature. HMAC proves authenticity and integrity, not confidentiality.
"Hashing proves who sent the message"
A plain SHA-256 hash can be computed by anyone — it proves nothing about origin. Only HMAC (or digital signatures using asymmetric keys) can authenticate the source of a message.
"HTTPS makes HMAC unnecessary"
HTTPS protects data in transit between client and server but does not authenticate the request at the application level. A valid HTTPS request can still be forged or replayed by someone with network access. HMAC authenticates at the message level, independently of the transport.
"HMAC is stronger encryption"
HMAC and encryption serve different purposes. HMAC is not a form of encryption at all. Comparing them as "stronger" or "weaker" encryption misframes the problem. Use encryption for confidentiality; use HMAC for authentication.
Frequently Asked Questions
Related Tools
Related Guides
HMAC is central to API authentication — see the API Authentication Methods guide for how HMAC signing compares to API keys, JWTs, and OAuth.