HMAC-SHA256 標籤是透過 SHA-256 壓縮函式，將共用密鑰與訊息的確切位元組結合後，所計算出的 32 位元組雜湊輸出；接著產生固定 64 個字元的十六進位字串，或 44 個字元的 Base64 字串。持有相同密鑰的驗證者可以重新計算，以確認訊息未遭修改。NIST FIPS 198-1 所定義的建構會將密鑰混入內層與外層雜湊處理，因此密鑰本身絕不會出現在摘要中。輸出具有確定性：任何知道相同密鑰、並將相同位元組序列輸入演算法的一方，都必定得到相同標籤。HMAC 不會加密訊息——任何看到純文字的人仍可讀取，而任何取得密鑰的人都能偽造有效標籤，因此安全性實際上取決於密鑰處理方式。若任務是使用已知密鑰產生 HMAC-SHA256 標籤，實際工作就是確保輸入位元組完全正確，並選擇接收端點所接受的編碼方式。
HMAC-SHA256 標籤實際上是什麼
HMAC 是「使用密鑰的雜湊訊息驗證碼」(keyed-hash message authentication code)。它以底層雜湊函式——此處為 SHA-256——為基礎，搭配兩個衍生密鑰：一個在雜湊前混入訊息，另一個在雜湊後混入結果。NIST FIPS 198-1 發布的定義使此建構具備可證明的安全性，只要底層雜湊仍具備碰撞抗性或偽隨機性。無論訊息大小為何，HMAC-SHA256 標籤的長度始終正好是 32 位元組：單一字元訊息與數百萬位元組訊息都會產生相同的 64 個十六進位字元輸出。
此標籤同時證明兩件事。第一，持有密鑰的驗證者可以根據收到的位元組重新計算標籤並確認相符，藉此證明位元組在傳輸途中未被更改。第二，任何能計算出相符標籤的人必定知道該密鑰，藉此驗證傳送者身分。此標籤無法證明的是機密性——在所有常見協定中，純文字訊息都會與標籤一同傳送，而攔截到這組資料的任何人都能看到明文。
第三項值得注意的性質是，標籤並非單純由訊息雜湊而來。兩則純文字相似的訊息會產生完全無關的標籤，因為秘密資料會在每個步驟混入，因此輸出無法作為未共用密鑰之各方所交換訊息的指紋。因此，HMAC 標籤是驗證與完整性用途的基本機制，而不是公開雜湊。
選擇正確的雜湊與輸入模式
演算法選擇取決於接收系統，而非個人偏好。使用 HS256 的 JWT 需要 HMAC-SHA256；新版區域中的 AWS Signature v4 使用 HMAC-SHA256；部分 API 與 IoT 協定則指定 SHA-384 或 SHA-512。當協定要求其中一種時變更雜湊，會產生接收端拒絕的標籤，因此第一個決策是閱讀協定規格，確認其要求完整長度的 HMAC-SHA256 標籤。
下一個決策是密鑰與訊息的編碼方式。UTF-8 模式將輸入視為 Unicode 文字，因此外觀明顯的字串 "café" 實際上有五個位元組，而 🛡 等表情符號各佔四個位元組。十六進位模式只接受偶數個 0–9 與 a–f 字元，並將其解碼為欄位的實際位元組；它會拒絕 "0x" 前置字元、內部空格、冒號及奇數半位元組數量，以免格式字元意外地悄悄變更協定值。每個解碼後的欄位上限為 1,000,000 位元組，介面也會拒絕空白密鑰與空白訊息，以防止意外點擊。HMAC 產生器 為密鑰和訊息提供這些模式，兩者可以分別選擇。
密鑰與訊息可以分別使用不同模式。常見做法是以十六進位位元組輸入已發布的測試向量，同時將訊息視為純 UTF-8 文字；或輸入易於人讀取的密鑰，同時讓訊息來自二進位協定欄位。唯一規則是位元組完全一致：接收端將送入 HMAC 的任何位元組，都必須與此處輸入的位元組相同，不能有額外空白、尾端換行或前置識別碼。
如何產生 HMAC-SHA256 標籤
- 確認協定要求完整 HMAC-SHA256 標籤（32 位元組），而非截短值，然後在工具中選擇 SHA-256。
- 輸入秘密密鑰。如果密鑰是人類可讀文字，請切換至 UTF-8 模式；如果它是二進位或已發布的密鑰，請切換至十六進位模式——貼上確切位元組，不要加上 0x 前置字元、冒號或空格。
- 輸入接收端將進行雜湊的訊息。訊息的 UTF-8 或十六進位模式可與密鑰模式分開選擇；如果協定會正規化空白，請先套用該規則再貼上。
- 點擊產生。HMAC 產生器會在同一個步驟中將完整標籤呈現為小寫十六進位及標準填充式 Base64，因此無需重新輸入任何內容即可取得兩種編碼。
- 複製協定要求的編碼。記錄檔、命令列工具及多數 API 使用十六進位；HTTP 標頭、JWT 及重視長度的環境則使用 Base64。
- 不要截短標籤，不要加入版本或演算法前置字元，也不要在接收系統未記載此要求時改用 Base64url——外觀相似的字串並不能互換。
安全地讀取與分享輸出
十六進位與 Base64 不是不同的標籤，而是相同 32 位元組的兩種呈現方式。十六進位形式每個位元組使用兩個字元，因此 SHA-256 標籤始終是 64 個字元。Base64 形式會將三個位元組分組為四個字元，並填充至 4 的倍數；對 32 位元組輸入而言，會產生 44 個字元，結尾有單一 '=' 填充字元。兩者之間的轉換不會遺失資料，解碼後會產生相同位元組。
不可互換的是標準 Base64 與 Base64url。適用於 URL 的變體會以 '-' 取代 '+'、以 '_' 取代 '/'，通常也會移除填充，因此以其中一種編碼建立的權杖，會被另一種編碼的嚴格解碼器拒絕。HMAC 產生器會輸出標準填充式 Base64；只有協定明確要求時才轉換為 Base64url。相同的注意事項也適用於帶前置字元的輸出，例如字面 "hmac-sha256=" 或 "v1."——這些是較高層級協定加入的封裝慣例，不是 HMAC 標籤本身的一部分。
操作衛生與位元組準確性同樣重要。從符合協定需求的密碼學安全隨機來源產生密鑰資料，透過受保護的管道散佈，依用途區分密鑰，並在疑似遭入侵後輪替。人類密碼的熵值很低，不得直接使用——必須將密碼轉為密鑰時，請使用協定記載的密碼型 KDF（PBKDF2、bcrypt、scrypt 或 Argon2）處理，並使用衍生位元組作為 HMAC 密鑰。切勿將正式環境的秘密貼到共用或不受信任的裝置，並務必在伺服器上使用常數時間函式，將收到的標籤與重新計算的標籤進行比較，以免計時側通道洩漏逐位元組相符程度。
為何不同工具產生的標籤有所差異
當兩個系統對外觀相同的輸入產生不同標籤時，原因幾乎總是位元組層級的不符，而非真正的互通性問題。以下檢查清單涵蓋任何多餘字元可能改變結果的各個面向：
- 雜湊選擇——SHA-256、SHA-384 與 SHA-512 分別產生 32、48 與 64 位元組的標籤。
- 密鑰編碼——UTF-8 位元組與解碼後的十六進位位元組；同一個字可能因附加符號、正規化及多位元組字元而成為不同的位元組序列。
- 訊息編碼——UTF-8 文字、十六進位位元組或 Base64 解碼後的輸入，以及雜湊前套用的空白與換行慣例。
- 標籤截短——即使兩個標籤看似有關，截取前 16 位元組後仍是不同值，而任何截短都必須由協定明確指定。
- 輸出編碼——標準 Base64 與 Base64url，或在接收端要求嚴格時，使用大寫與小寫十六進位。
HMAC 產生器固定提供 8 個完整的 RFC 4231 相容性標籤，涵蓋短密鑰、重複位元組的二進位密鑰與資料、小於摘要的密鑰，以及跨越雜湊區塊界限的資料。SHA-256 與 SHA-512 各自以 4 個獨立輸入進行檢查，介面也提供 WebCrypto 定義的 SHA-384 選項。當接收端拒絕標籤時，最快恢復一致性的方法是先根據已發布向量確認密鑰與訊息的確切位元組，再比較演算法與輸出編碼。
雜湊變體比較
| 雜湊 | 輸出位元組 | 十六進位長度 | Base64 長度 | 常見用途 |
|---|---|---|---|---|
| SHA-256 | 32 | 64 | 44 | JWT HS256、AWS Signature v4 |
| SHA-384 | 48 | 96 | 64 | 高保證協定 |
| SHA-512 | 64 | 128 | 88 | 舊版伺服器與 64 位元原生程式碼 |
以瀏覽器為基礎的實作會將所選位元組匯入為無法匯出的 WebCrypto HMAC 密鑰，使用選定的雜湊執行 subtle.sign，並將產生的標籤分別呈現為小寫十六進位與標準填充式 Base64——所有輸入都會保留在目前的分頁中，絕不會傳送至伺服器。