HMAC 產生器實際產出什麼
HMAC 產生器會計算出一個金鑰雜湊訊息鑑別碼——這是一個固定大小的標籤，用來證明訊息是由持有同一把秘密金鑰的一方所產生，而且在傳輸過程中沒有遭到修改。其輸出是一段由位元組組成的確定性字串，完全由三個輸入決定：所選的雜湊函式、秘密金鑰的確切位元組、以及訊息的確切位元組。任何知道同一把秘密、並餵入相同位元組序列的驗證者，都會算出完全相同的標籤。金鑰、訊息或演算法若有任何更動，都會產生一個截然不同的標籤——這正是此機制能用於偵測竄改與認證送方的原因。
這個標籤既小又便於攜帶。使用 SHA-256 時，結果正好是 32 個位元組；使用 SHA-384 時是 48 個位元組；使用 SHA-512 時則是 64 個位元組。這些位元組可以呈現為小寫十六進位，或是標準帶填補的 Base64，兩種呈現方式描述的是完全相同的數值。HMAC 產生器頁面會將兩種呈現方式並列顯示，讓驗證者能以周邊協定所期望的形式進行比對。
同樣重要的是，標籤「不能」做什麼。HMAC 並不會加密訊息——任何看到明文的人都能讀取內容。HMAC 也無法辨識個人身分——它只能證明產生標籤的一方持有共用秘密。此外，HMAC 並不能取代數位簽章，因為標籤無法由不知道金鑰的第三方進行驗證：要在兩端重新產生標籤，必須使用同一把秘密。
HMAC 標籤在底層是如何建構出來的
NIST FIPS 198-1 所定義的建構方式，無論選用哪一種 SHA-2 雜湊，都遵循相同的結構。在內部，演算法會將金鑰填充或雜湊至雜湊區塊大小，將填充後金鑰的一份副本與稱為 ipad 的常數做 XOR，將結果與訊息一起雜湊，再將填充後金鑰的另一份副本與另一個稱為 opad 的常數做 XOR，最後把兩個中間輸出一起雜湊。這種雙重雜湊的結構，正是讓秘密得以避開底層雜湊函式通常被攻擊的方式。
您不需要親自實作這些細節。HMAC 產生器會以您選擇的雜湊演算法，將您的金鑰匯入為不可匯出的 WebCrypto HMAC 金鑰，接著呼叫 subtle.sign，並將完整回傳的標籤呈現為小寫十六進位與帶填補的 Base64。填補常數、內部雜湊與外部雜湊全部都在瀏覽器的密碼學模組中完成，因此逐步建構的細節對您而言不可見，但在數學上等同於 FIPS 198-1 的參考實作。
其關鍵在於每一個位元組都不能馬虎。訊息末端的一個空白差異、一個帶腔調字母的 UTF-8 編碼特性、或十六進位輸入中翻轉的一個位元，都會產生一個完全不相關的標籤。這個特性正是讓 HMAC 能偵測修改的原因，但也說明了您必須在將內容貼入工具之前，先弄清楚協定實際預期的是哪些位元組。
在 SHA-256、SHA-384 與 SHA-512 之間擇一使用
您選擇的雜湊演算法，會決定標籤長度、底層區塊大小以及協定相容性。您不該挑自己最喜歡的那一個，而應該挑接收端準備好要驗證的那一個。
| 雜湊演算法 | 標籤長度 | 內部區塊大小 | 典型用途 |
|---|---|---|---|
| HMAC-SHA-256 | 32 bytes | 64 bytes | 大多數 REST API、webhook 簽章、JWT 資料區段 |
| HMAC-SHA-384 | 48 bytes | 128 bytes | 高保證等級的設定檔、要求更強 SHA-2 摘要的合規規範 |
| HMAC-SHA-512 | 64 bytes | 128 bytes | 長期效力的憑證、內部服務對服務的信任機制，且不要求較短的雜湊時 |
若協定文件寫的是 HMAC-SHA256 且未加其他限定，指的就是 SHA-256。若寫的是 HMAC-SHA512，指的就是 SHA-512。若只寫 HMAC 並讓您自行選擇，則一般網路用途應優先選 SHA-512；至於希望在不改變協定結構的前提下取得更長標籤的內部系統，則可改採 SHA-512。
金鑰與訊息的 UTF-8 與 Hex 模式
HMAC 產生器讓您可以為金鑰欄位與訊息欄位分別獨立設定 UTF-8 或 hex 模式。這很重要，因為兩種模式以不同的方式保留位元組。UTF-8 模式適合用來輸入或貼上人類可讀的文字——字母、帶腔調的字元、CJK 字串與表情符號會即時編碼為標準的 UTF-8 位元組序列。Hex 模式則更安全，適合用於已公開的測試向量、原始二進位資料酬載，以及任何以位元組字面序列形式記載秘密或資料的協定。
Hex 模式僅接受偶數個十六進位數字，並保留包括零在內的每一個位元組。它會拒絕像 0x 這類前置詞、內嵌空白、冒號以及奇數的 nibble，因此一個多餘的格式字元不會悄悄地改變協定數值。UTF-8 模式則會直接編碼可見的空白與換行符號——這在處理一般文字時是個優勢，但若接收端系統對換行慣例有特定預期，則可能造成風險。
實務上的原則是：當規格給的是 ASCII 位元組或字串時，請以 UTF-8 模式貼入並再次確認編碼；當規格給的是十六進位傾印或已知的位元組序列時，請切換至 hex 模式，逐字元輸入而不加任何裝飾。
如何使用 HMAC 產生器產生標籤
- 開啟 HMAC 產生器，並選擇 SHA-256、SHA-384 或 SHA-512——挑選您所依循的協定或標準所要求的那一個。此處不相符是導致計算出來的標籤與預期標籤不一致最常見的原因。
- 對於金鑰與訊息這兩個欄位，請根據協定記載的形式，分別獨立選擇 UTF-8 或 hex。若金鑰是原始秘密字串，請使用 UTF-8；若訊息是來自工具的十六進位傾印，請使用 hex。
- 請逐位元組正確輸入。在 UTF-8 模式下，輸入或貼上時不要附加看不見的尾端空白。在 hex 模式下，僅輸入偶數個十六進位字元——不加 0x 前置詞、不加空白、不加冒號。
- 觸發計算並讀取完整的標籤。頁面永遠會顯示所選雜湊的完整輸出，因此 32、48 或 64 位元組的標籤會完整呈現而不會被截斷。
- 複製協定所期望的編碼格式——多數 API 與 webhook 主體使用小寫十六進位；對於需要傳遞文字安全封裝的系統，則使用標準帶填補的 Base64。只有當規格明確要求時，才進行轉換或修剪。
- 請在伺服器端以常數時間函式與預期值進行比對，絕不要使用簡單的字串相等測試，以免洩漏已相符的前導位元組數量。
如何正確辨讀 Hex 與 Base64 輸出而不致混淆
同一個 32 位元組的 HMAC-SHA-256 標籤，會對應到 64 個小寫十六進位字元，以及 44 個 Base64 字元。它們代表相同的位元組，但並非可以互換的字串。若驗證端預期的是 hex 而您送出 Base64，比對結果必定失敗；若驗證端預期的是 Base64url 而您送出標準 Base64，加號、斜線與填補字元的差異也可能導致比對失敗。
HMAC 產生器回傳的是標準帶填補的 Base64，使用加號、斜線與等號填補。它不會產生 Base64url，也不會在前面附加像 sha256= 這樣的演算法識別碼，更不會把訊息與其標籤包裹在一起。這些轉換屬於協定層級的責任。若您需要這些處理，請在從工具複製出原始位元組之後再進行，絕對不要在之前。關於哪種雜湊對應哪種編碼的簡明提示，可參考 HMAC 產生器速查表：雜湊、編碼與輸出規則，其中列出了確切的對應關係。
限制、空輸入與瀏覽器端處理
頁面將每個解碼後的欄位上限設定為一百萬位元組，遠高於一般 API 與 webhook 酬載的規模。即使部分底層標準允許零長度輸入，介面仍會拒絕空的金鑰與空的訊息——這個拒絕機制只是為了避免一次不慎的點擊，就為錯誤的輸入產出一個看似有意義的標籤。對於長時間執行的工作，會搭配一個身分識別權杖：若 Web Crypto 仍在計算時您變更了某個值，較舊的結果就無法覆蓋較新的狀態。
所有處理都在目前的瀏覽器分頁中透過 Web Cryptography API 執行，輸入內容不會離開裝置。這代表此工具適合用於開發階段的秘密，但您仍應避免將正式環境的憑證貼入不受信任的機器，因為只要秘密還在畫面上，它就會存在於分頁的記憶體中。對於需要高熵金鑰的協定，請使用產生的金鑰，透過受保護的管道進行派送，依照用途區分不同的金鑰，並在疑似遭到破解時予以更換。
依據 RFC 4231 驗證正確性
RFC 4231 測試向量 定義了一小組輸入及其在 SHA-224、SHA-256、SHA-384 與 SHA-512 下所對應的預期 HMAC 標籤，涵蓋了短金鑰、重複位元組的二進位金鑰、短於摘要長度的金鑰，以及跨越雜湊區塊邊界的訊息等案例。HMAC 產生器已對齊這些案例中八組完整的符合性標籤，因此確認此工具行為是否符合您的協定需求，最簡單的方式就是輸入一個有文件記載的 RFC 4231 案例，並將其標籤與 RFC 中公布的值進行比對。
在這些向量上達成一致，僅能證明演算法、位元組解讀方式以及編碼呈現都是正確的。它無法證明您的金鑰確實保密、您的訊息確實可信、或您為協定選對了雜湊演算法——這些都是工具範疇之外的決策，必須在您按下「產生」之前，先依據相關規範做出判斷。