Why a SHA-256 Hash Is Not an HMAC Signature

If an API asks for HMAC-SHA256, a plain SHA-256 digest is the wrong operation even when both results look like 64 hexadecimal characters. First identify whether the contract requires an unkeyed hash or a message authentication code calculated with a shared secret key.

This guide uses an original public demonstration message. It sends no API request and uses no account credentials.

Separate the two operations

RFC 2104 defines HMAC using a hash function and a secret key with a specific inner and outer construction. It is not equivalent to putting a key before or after a message and hashing the combined text once.

Some API documentation calls the resulting code a signature. HMAC is a shared-key message authentication code, rather than a public-key digital signature. The MDN signing reference explains that HMAC uses the same key for creation and verification. Parties holding that key can create the code.

Confirm what the on-site generator actually calculates

The SHA-256 Generator encodes entered text as UTF-8 and calls a digest operation. Its controls provide algorithm and output-format choices, but no HMAC key input.

1. Set Algorithm to SHA-256 and Output format to Hexadecimal.
2. Leave Uppercase hex output unchecked.
3. Enter demo-order-42 in Text to hash, without a final newline.
4. Select Generate hash and compare the result below.

8f2403329ea5c9932fdef206df95338596cd3b159098c4cec158d98461acb794

The input contains 13 UTF-8 bytes. This is the plain digest of those bytes, not an authenticated API signature. MDN distinguishes digest from HMAC and directs HMAC operations to the signing interface.

Compare a deliberately public HMAC example

For comparison, applying HMAC-SHA256 locally to the same message with the intentionally public demonstration key public-demo-key produces this full-length lowercase hexadecimal code:

c77a886ac499650a2c15e4040314e3e06e3de56fdf476d1080f73430b24a2094

This calculation uses the UTF-8 bytes of the displayed message and key, with no added line break. This key is public demonstration data and supplies no secret for real authentication. The on-site generator does not produce this HMAC result.

Both displayed outputs contain 64 hexadecimal characters, but their matching lengths do not identify the operation. Switching the generator to Base64 or changing letter case only changes its output representation; it does not introduce a key or turn the digest into HMAC.

Read the API signing contract before fixing a mismatch

Record these four decisions from the actual integration documentation:

1. Construction: does it explicitly require HMAC-SHA256, plain SHA-256, or another operation?
2. Signed input: which exact bytes are covered, and how is any required signing string assembled?
3. Key: which configured secret and documented key representation does the implementation use?
4. Result representation: does the receiving field expect hexadecimal, Base64, a prefix, or another documented format?

Do not assume the visible JSON body is necessarily the entire signing input, or invent a sorting rule to make two examples match. Preserve the documented construction and input assembly. The separate guide to text hash differences covers byte-level mismatches after you have established that both sides perform the same operation.

Use an HMAC implementation for an HMAC requirement

Use the supported integration SDK or a maintained cryptographic library with an explicit HMAC operation. Reproduce a documented public test vector before investigating a real request. Keep real signing keys in the intended protected application environment, rather than inserting them into a plain text-hash box.

Record the algorithm, message bytes, key convention and expected representation with the test result. A successful calculation is one part of an integration check; it does not establish that an API accepted a request or that every authentication rule was satisfied.