一個完全在瀏覽器中運作的 HMAC 產生器替代方案，能夠從精確的密鑰與訊息位元組計算出 HMAC-SHA-256、HMAC-SHA-384 和 HMAC-SHA-512 標籤，而無需將任何輸入傳送到遠端伺服器。這個基於瀏覽器的 HMAC 產生器使用標準的 Web Cryptography API 將密鑰匯入為不可匯出的控制代碼，使用 subtle.sign 對訊息進行簽署，並回傳以小寫十六進位和標準填補 Base64 呈現的完整標籤。由於運算完全保留在當前的分頁中，無論是密鑰還是訊息都絕不會離開裝置。針對密鑰與訊息各自獨立的 UTF-8 或十六進位選擇，讓您能夠逐位元組重現已發布的測試向量，同時 SHA-256、SHA-384 和 SHA-512 提供三種標籤長度 — 分別為 32、48 和 64 位元組 — 也就是現代通訊協定實際使用的長度。八組完整的 RFC 4231 一致性測試標籤已內建於實作中，因此這個替代方案符合規格要求，而不僅僅是近似規格。簡而言之，這個替代方案並非精簡版的取代品；它是相同的演算法，具備更嚴格的位元組控制以及零資料外洩。
為何尋找 HMAC 產生器的替代方案？
大多數開發人員第一次接觸 HMAC 產生器時，都是透過託管的 API、像 OpenSSL 這類的命令列工具，或是會將輸入上傳到遠端伺服器的第三方網頁工具。這些方法雖然都能運作，但各自都會產生摩擦，促使團隊尋求更好的替代方案。託管的 API 會對您的請求進行計量，在負載過高時回傳錯誤，並將您的密鑰綁定在他人的基礎架構上。命令列工具需要本機安裝、正確的環境設定，以及處理二進位資料的殼層指令，而這往往會剝除或跳脫您真正打算傳送的位元組。第三方線上工具常一邊宣稱便利，一邊悄悄將您的密鑰與訊息傳送到他們的後端，有時會記錄下來，有時會儲存起來，幾乎從不說明這些資料在傳輸過程中會如何處理。基於瀏覽器的替代方案能解決上述所有問題：資料不會離開分頁、無需安裝、沒有限流，而且底層演算法與主流瀏覽器在 HTTPS 本身所信任的 Web Crypto 基元相同。
HMAC 產生器替代方案必須保留的特性
只有在能夠逐位元組產生驗證器可接受的標籤時，更換工具才是安全的。這個要求排除了幾種常見的捷徑。替代方案必須讓您明確選擇 SHA-256、SHA-384 或 SHA-512，因為每種變體會產生不同長度的標籤，且許多通訊協定會指定其中一種而拒絕其他。替代方案必須讓您能夠為密鑰與訊息各自獨立選擇 UTF-8 文字或原始十六進位位元組，因為您實作的通訊協定會以各自的方式定義每個輸入，而編碼不符是在接收端發生「標籤不符」錯誤最常見的原因。替代方案必須永遠同時以十六進位和標準 Base64 回傳完整標籤，絕不能為了配合 UI 欄寬而悄悄截斷或填補輸出。替代方案必須將密鑰資料保留在瀏覽器分頁內 — 不能放在帳號後面、伺服器記錄中、或 CDN 邊緣節點上。如需深入了解 HMAC 中的位元組一致性，請參閱這篇關於對應通訊協定精確位元組的指南。
在瀏覽器中本機產生 HMAC 標籤
使用 HMAC 產生器 作為即插即用的替代方案需要三個明確的步驟。每個步驟都很小，但跳過任何一個都是位元組錯誤的根源。
- 選擇雜湊函式並確認標籤長度。開啟 HMAC 產生器，從演算法控制項中選擇 SHA-256、SHA-384 或 SHA-512。在產生任何結果之前，請閱讀您目標的通訊協定或 API 文件，並確認它預期該變體的完整標籤：SHA-256 為 32 位元組，SHA-384 為 48 位元組，SHA-512 為 64 位元組。如果該通訊協定預期截斷的標籤、具有演算法前綴的封包，或特定的標準化請求字串，則這是您必須自行套用的下游轉換作業；產生器永遠只會輸出完整的標籤。
- 為密鑰與訊息各自獨立設定 UTF-8 或十六進位，然後輸入精確的位元組。密鑰控制項與訊息控制項各自擁有獨立的編碼切換功能。當通訊協定將密鑰撰寫為可列印字元、含變音符號的字母、CJK 字串或表情符號時，請選擇 UTF-8，並記住 UTF-8 會將這些字元編碼為多個位元組。當通訊協定以位元組字串形式發布該值時 — 例如當您要重現 RFC 4231 測試向量之一 — 請選擇十六進位，並只貼上偶數個十六進位數字，不含 0x 前綴、不含冒號分隔符、也不含尾端空白字元。介面會拒絕奇數的半位元組與多餘的格式，避免任何一個多餘字元悄悄改變通訊協定值，同時也會直接拒絕空密鑰與空訊息，以防止誤觸。
- 產生標籤，然後複製通訊協定所預期的編碼格式。按下產生按鈕，等待結果面板出現，然後複製符合驗證器所接受格式的小寫十六進位或標準填補 Base64 輸出。十六進位與 Base64 只是同一標籤位元組的兩種呈現方式，因此請勿在通訊協定要求其中一種時貼上另一種。只有在通訊協定規格明確要求時，才進行兩者之間的轉換，或套用通訊協定的標準化請求字串，並且絕對不要手動截斷標籤。
SHA-256、SHA-384 或 SHA-512 — 如何選擇
這三者皆屬於 SHA-2 家族，且都被視為密碼學上強度足夠的演算法，但它們會產生不同長度的標籤，且內部區塊大小也不同。選擇幾乎總是由通訊協定決定，而非個人偏好。AWS SigV4 要求使用 HMAC-SHA-256。許多部署中的 JWT 也使用 HMAC-SHA-256，而某些簽章機制（例如特定的支付整合與特定的 OAuth 設定檔）則要求使用 HMAC-SHA-512。如果通訊協定未指定，HMAC-SHA-256 是互通性最廣的預設選項。基於瀏覽器的產生器透過標準的 Web Cryptography API HMAC 演算法項目 實作了這三種演算法，因此無論通訊協定強制規定哪種變體，都能套用相同的工作流程。
| 演算法 | 區塊大小 | 標籤長度 | 十六進位字元數 | Base64 字元數 |
|---|---|---|---|---|
| HMAC-SHA-256 | 512 bits | 32 bytes | 64 | 44 (with padding) |
| HMAC-SHA-384 | 1024 bits | 48 bytes | 96 | 64 (no padding) |
| HMAC-SHA-512 | 1024 bits | 64 bytes | 128 | 88 (with padding) |
這些是由 NIST FIPS 180-4 所定義，並在 Web Crypto 規格中重現的固定大小。如果您實作的通訊協定預期不同的長度 — 例如某些舊版整合使用 16 位元組的截斷 SHA-256 標籤 — 則截斷是另一個獨立的步驟，並非由產生器代為執行。
UTF-8 或十六進位 — 對應通訊協定的輸入位元組
HMAC 產生器讓您能夠獨立設定密鑰與訊息的編碼方式。這並非只是外觀選項，而是產生遠端驗證器能接受之標籤的唯一方式。當通訊協定將密鑰描述為文字時（例如以 "sk_live_4f8a9..." 顯示的 API 密鑰），以及當訊息為可讀內容（如 JSON 主體）時，UTF-8 是正確的選擇。當通訊協定以位元組字串形式發布該值、當您要重現測試向量，或當輸入包含 NUL 或其他文字欄位會破壞的非可列印位元組時，十六進位是正確的選擇。
| 輸入模式 | 使用時機 | 位元組處理方式 |
|---|---|---|
| UTF-8 | API 密鑰、權杖、CJK 字串、表情符號、含變音符號的字元 | 每個字元編碼為一到四個位元組；空白字元與換行字元屬於輸入的一部分 |
| 十六進位 | 已發布的測試向量、二進位密鑰、原始通訊協定欄位 | 僅接受偶數個數字；拒絕 0x 前綴、空格、冒號與奇數的半位元組 |
更換工具時一個常見的錯誤是將十六進位字串輸入到 UTF-8 欄位，反之亦然。介面也將每個解碼後的欄位上限設定為 1,000,000 位元組，因此非常大的密鑰或訊息會超出支援的大小。結果就是一個看似有效但完全不同的標籤，驗證器會以看似神秘的原因將其拒絕。如果您不確定該通訊協定預期哪種模式，請找到一個已發布的有效標籤範例，並從中反向推導其編碼方式。
十六進位與 Base64 輸出 — 相同的位元組，兩種呈現
產生器永遠會將完整標籤呈現兩次：一次為小寫十六進位，一次為標準填補 Base64。這兩者是同一組位元組字串的兩種文字表示法，而非兩個不同的標籤。兩者之間的選擇完全取決於驗證器的預期。像 Stripe 的 webhook 簽章機制會預期在標頭中使用十六進位。許多使用 HMAC 進行請求驗證的 REST API 則預期在 Authorization 欄位中使用標準 Base64。某些規格使用 Base64url — 一種不含填補字元，且在位置 62 與 63 使用兩個不同字元的 URL 安全變體 — 即使大多數字元重疊，該變體仍與標準 Base64 不同。
如果通訊協定要求 Base64url，請複製標準 Base64 輸出並使用其他工具進行轉換，或自行移除填補字元並替換為兩個 URL 安全的字元。請勿在預期 Base64url 的位置貼上標準 Base64 字串；有些驗證器會意外接受，而有些則會拒絕所有請求，且各實作之間的失敗模式無法預測。Web Crypto HMAC 運算本身只回傳原始位元組；呈現方式純粹是顯示上的選擇，永遠不會改變密碼學上的值。
Common Pitfalls When Switching HMAC Tools
A few recurring errors catch developers the first time they migrate to a browser-based HMAC generator:
- Truncating the tag visually. Some UIs trim the output to fit a column. The HMAC Generator shows the full tag, so any truncation must come from the protocol, not from the screen.
- Mixing encodings. Hex and Base64 are interchangeable representations of the same bytes, but Base64url is not standard Base64, and some "Base64" decoders reject valid input that contains lowercase letters or no padding.
- Forgetting the message encoding. A JSON body can be re-serialized with different whitespace, a different key order, or different escape sequences. The exact bytes that reach the server are the bytes you must hash, not a canonicalized version you reconstruct afterwards.
- Assuming a password is a strong key. A human password has low entropy and should not be used as an HMAC key directly. Use the protocol's specified password-based KDF, or generate a high-entropy secret and distribute it through a protected channel.
- Pasting production secrets into an untrusted device. The browser-based generator does not upload anything, but the device itself must be trusted. Avoid shared or kiosk machines for live production keys.
- Comparing tags with a non-constant-time function. The browser side does not perform tag comparison, but the server-side verifier should always compare with a constant-time function to avoid timing leaks.
Each of these is a small detail on its own, and any one of them is enough to make a verifier reject a perfectly correct message. When switching tools, the safest discipline is to pick one RFC 4231 test vector, run it through the new generator, and confirm the tag matches the published value exactly before relying on it for production traffic.
Related reading: Morse Code Translator API Alternative That Runs Locally.