HS256 JSON Web Token 是一段精簡的三段式字串，產生方式為：將固定標頭 {"alg":"HS256","typ":"JWT"} 以 base64url 編碼、將嚴格的 JSON 聲明 (claims) 載荷以 base64url 編碼，再附加第三段，該段保存以共用密鑰對位元組序列 header.payload 計算 HMAC-SHA-256 後的 base64url 編碼結果。其精簡格式定義於 RFC 7515，HMAC-SHA-256 演算法及其最小金鑰長度定義於 RFC 7518，整個簽章透過 Web Crypto 在瀏覽器中計算，因此密鑰與聲明絕不會離開當前分頁。由於 HS256 是訊息驗證碼 (message authentication code)，並非加密機制，因此任何收到該 token 的人無需密鑰即可解碼標頭與載荷。簽章能讓驗證者事後偵測是否遭到竄改，而密鑰則將這種偵測能力綁定到簽發方。最終結果是一個可攜的字串，形如 xxxxx.yyyyy.zzzzz，任何平台上的 JOSE 相容函式庫只要知道同一把密鑰、同一種演算法、同一套聲明政策，都能加以驗證。

generate jwt token with secret key online
線上以密鑰產生 JWT Token (HS256)

密鑰規則：32 個 UTF-8 位元組及其原因

對 HS256 而言，密鑰就是整個信任錨點 (trust anchor)。HMAC-SHA-256 演算法使用 256 位元的內部狀態，因此密鑰長度預期應達到 RFC 7518 所述的 32 位元組 / 256 位元下限。任何短於此的值都會削弱對暴力破解的密鑰空間，因此 JWT 產生器在簽署開始前，會拒絕長度低於 32 個 UTF-8 位元組的密鑰。

由於密鑰是以位元組序列進行雜湊，字元數與位元組數可能不一致。一個 32 字元的 ASCII 字串剛好是 32 個位元組。一個包含任何非 ASCII 字元的 32 字元字串——無論是表情符號、附加腔音符號的拉丁字母或中日韓字符——都會超過 32 個位元組，因為 UTF-8 會將這些碼點編碼為 2、3 或 4 個位元組。此工具將您的密鑰視為原始 UTF-8，再將這些位元組交給 Web Crypto 作為 HMAC 金鑰。

產生器上的隨機按鈕是為測試固件 (test fixtures) 設計的。它會從瀏覽器的安全隨機來源擷取 32 個密碼學安全隨機位元組，並以 64 個十六進位字元顯示。這 64 個字元接著會重新以 UTF-8 編碼並作為 HMAC 密鑰使用，產生 32 個位元組的密碼學熵，並以 64 字元的十六進位字串呈現。請將顯示的字串視為可見的測試資料：任何擷取到它的瀏覽器分頁、螢幕擷圖、剪貼簿或聊天記錄，都已擷取到該密鑰。

對於任何本機開發以外的場景，密鑰應存放在受控儲存機制中，例如保險庫或雲端密鑰管理服務，而非置於設定檔或聊天訊息裡。產生器的角色是協助您在不必撰寫腳本的情況下簽署一顆開發用 token，而非用來佈建正式環境的憑證。

使用 JWT 產生器產生 HS256 token

  1. 在瀏覽器中開啟 JWT 產生器。頁面會顯示兩個輸入窗格與一個 token 預覽區；在您點選產生之前，不會執行任何動作。
  2. 將嚴格的 JSON 物件貼入聲明窗格。物件必須以 { 開頭、以 } 結尾，且不得包含註解、尾端逗號、NaN、Infinity、undefined 或 JavaScript 運算式。陣列與 null 會在解析階段被拒。
  3. 將非正式環境的密鑰輸入密鑰欄位，或點選隨機按鈕，以 64 個十六進位字元（背後由 32 個密碼學安全隨機位元組支援）填入。
  4. 確認密鑰至少有 32 個 UTF-8 位元組。頁面會顯示長度提示，協助您判斷非 ASCII 文字是否已將位元組數推高於字元數。
  5. 點選產生。頁面會將固定標頭與您的聲明進行 base64url 編碼，以密鑰位元組對 header.payload 進行 HMAC-SHA-256 簽署，並輸出不帶填充 (padding) 的第三段簽章。
  6. 檢視畫面上的三個段。標頭解碼後應為 {"alg":"HS256","typ":"JWT"}；載荷應與您輸入的內容逐位元組相符；簽章應是唯一會在您編輯密鑰時變動的段。
  7. 複製完整的 xxxxx.yyyyy.zzzzz 字串。請將剪貼簿視為洩漏媒介：在將 token 貼入測試環境後將其清除，且絕不在其他地方重複使用該密鑰。

讀取三個精簡段

精簡格式由三個以句點分隔的段組成。每一段都是不帶等號填充的 base64url 字串，因此段內只會包含 [A-Za-z0-9_-] 字元，且絕不以 = 結尾。

段來源編碼方式所承載內容
標頭 (Header){"alg":"HS256","typ":"JWT"}UTF-8 → base64url，無填充演算法與類型識別碼
載荷 (Payload)您的嚴格 JSON 聲明物件UTF-8 → base64url，無填充簽發者、受眾、主體、效期及任何自訂資料
簽章 (Signature)HMAC-SHA-256(header + "." + payload, secret bytes)base64url，無填充與密鑰綁定的完整性證明

JWT 產生器將標頭固定為 alg HS256、typ JWT。固定演算法可避免一種靜默降級情況——使用者將 alg: none 或 alg: RS256 貼入標頭，而接收端盲目接受任何到來的形狀。其他演算法需要不同的金鑰類型，而瀏覽器端的密鑰流程僅模擬對稱式 HMAC 金鑰，因此頁面將選項鎖定。

載荷段即為您的 JSON 物件，除了精簡序列化之外不做任何正規化。驗證端使用 JSON.parse 應能重現您當初貼上的同一物件，包括鍵的順序，因為頁面輸出的精簡形式與 JavaScript 中同一步 JSON.stringify 所產生的結果相同。若您需要穩定的位元組序列以進行確定性驗證，請貼上一個已按您所需順序排序的聲明物件，並避免加入註解或尾端逗號。

簽章段會在每次產生時重新計算，因此任何輸入的變更——即便是密鑰中的單一位元組——都會產生完全不同的第三段。這正是讓驗證者能偵測竄改的特性，前提是驗證者使用同一把密鑰與同一種演算法。

使用您目標的 JOSE 函式庫驗證 token

JWT 產生器會輸出一個語法有效的 HS256 token，但它本身並不會對其輸出執行驗證的回返測試 (round-trip)。在您於任何環境信任該 token 之前，請將其交給您應用程式實際使用的 JOSE 函式庫，並要求進行明確、以政策為導向的檢查。

  1. 將複製的字串連同精確釘選為 HS256 的演算法傳遞給該函式庫的 verify 或 decode 函式。拒絕任何受保護標頭帶有不同 alg 的 token。
  2. 以您在產生器中使用的同一把密鑰作為驗證金鑰傳入。密鑰位元組必須完全相符，包括編碼方式、填充與結尾字元。
  3. 根據您預期的簽發者識別碼驗證 iss 聲明。為某個租用戶簽發的 token 不應被另一個租用戶接受。
  4. 根據您服務預期的受眾驗證 aud 聲明。為不同 API 核發的 token 並非您應接受的對象。
  5. 驗證 exp、nbf 以及您為時鐘飄移 (clock skew) 所設定的任何容差。拒絕已過期或尚未生效的 token。
  6. 若您的服務使用重放防護，請驗證 jti；若您的服務支援撤銷，請查詢撤銷清單。

正式環境的函式庫可透過一次呼叫搭配明確選項提供這些功能。驗證步驟正是多數演算法混淆 (algorithm-confusion) 與金鑰混淆 (key-confusion) 攻擊被攔截之處，因此即便 token 是您自行產生，也絕對不可略過。

若想更仔細地比較在同一瀏覽器流程中將 HS256 對照 RS256 的演算法差異，HS256 vs RS256 指南 將帶您逐一檢視在選擇對稱式密鑰流程前所考量的權衡。

JWT 產生器不做的事

此頁面的範圍僅限於產生開發用 token。它不會自動加入 iat、exp、nbf、iss、sub、aud、jti 或任何其他聲明。若您的驗證端預期 NumericDate 形式的 exp 聲明，您必須將該整數置於您的聲明物件中，以自 Unix 紀元起的秒數表示，而非 JavaScript 毫秒。

舉例而言，2026-01-01T00:00:00Z 這個瞬間對應的 NumericDate 值為 1767225600，因為 2026 年 UTC 起始瞬間的 Unix 紀元秒數即為 1767225600 秒。若您不慎貼入毫秒，驗證端會將您的效期解讀為數十億年之後或遙遠的過去，即便人類可讀的日期看似正確。

此頁面同樣不會驗證它剛產生的 token、聯繫身分提供者、發布 JWK、儲存金鑰、選擇 kid、加密聲明，也無法產生 RS256、ES256、EdDSA、JWE 或未受保護的 token。它不會自動輪換密鑰、稽核使用情形或撤銷已洩漏的 token。這些關注點都不屬於一個在記憶體中處理金鑰資料的瀏覽器頁面；它們屬於受維護的 JOSE 函式庫以及您應用程式的信任政策。

最後，此頁面並不宣稱獨特性。市面上還有其他基於瀏覽器的 JWT 工具，部分可讓您選擇不同演算法或接受未受保護的標頭。本產生器的刻意範疇為使用最少 32 位元組 UTF-8 密鑰的 HS256，因為這是在不增添可能悄悄削弱驗證之選項的前提下，開發流程最安全的形狀。

使用密鑰 JWT 的常見錯誤

過短的密鑰是最常見的失敗。低於 32 個 UTF-8 位元組會被拒絕，但貼上一個帶標點的單一字典詞，在您腦中可能通過字元測試，卻會在簽署時因位元組測試而失敗。若您的驗證端對看似正確的 token 抱怨簽章不符，首先應檢查的就是密鑰的位元組數，特別是涉及非 ASCII 字元時。

第二個錯誤是演算法不符。以 HS256 核發的 token，若驗證端設定為 HS384、HS512 或非對稱式演算法，即便密鑰恰好是同一字串也會驗證失敗。請在兩端都明確設置演算法白名單，並拒絕任何受保護標頭列出 alg: none 的 token。

第三個錯誤是聲明混淆。將簽發者與受眾搞混，或在多個租用戶間重複使用同一把測試密鑰，會產生在獨立環境中看似正常、卻在正式環境失敗的 token。產生器不會對這些政策錯誤提出警告；驗證端才會。

第四個錯誤是剪貼簿洩漏。複製 token 會使其經由剪貼簿歷史、螢幕擷圖、瀏覽器擴充功能、客服單與聊天記錄外洩。密鑰亦同。在此頁面上請僅使用非正式環境的聲明與密鑰，並輪換任何曾接觸到預定範圍之外環境的值。

若您正在權衡選項，JavaScript 按鍵代碼尋找器替代方案：本機擷取 對此有詳細說明。