JWT 解析工具
解碼和驗證 JSON Web Token，查看 Header、Payload 和 Signature
範例 JWT
什麼是 JWT？
JWT (JSON Web Token) 是一種開放標準 (RFC 7519)，用於在各方之間安全地傳輸資訊。JWT 由三部分組成，用點號分隔：Header（頭部）包含令牌類型和簽名演算法，Payload（載荷）包含聲明資料，Signature（簽名）用於驗證令牌完整性。JWT 常用於身份認證和資訊交換場景。 安全相關結果不能孤立判斷，還要結合金鑰、使用情境、演算法選擇和可信來源一起評估。
使用方式
使用方式
- 將 JWT 貼上輸入框，工具會自動解析並顯示 Header 與 Payload 內容
- 點選彩色標籤可複製對應的 Base64 編碼片段
- 在簽章驗證區輸入密鑰即可驗證簽章是否正確（支援 HS256/HS384/HS512 演算法）
- 關鍵資訊區會顯示常用聲明的解碼值，過期狀態以顏色區分
安全提示
- 此工具在瀏覽器本地執行，Token 不會上傳至任何伺服器
- JWT 僅負責編碼與簽章資料，並非加密，任何人都能解碼並查看內容
- 請勿在 JWT 中儲存敏感資訊（如密碼、信用卡號等）
- 正式環境中傳輸 JWT 請務必使用 HTTPS
使用場景
技術原理
JWT（JSON Web Token，RFC 7519）由三個部分組成——Header.Payload.Signature——以英文句點 '.' 連接。 Header：描述 token 型別和簽名演算法，例如 {"alg":"HS256","typ":"JWT"}。alg 決定 Signature 的計算方式；常見的有 HS256（HMAC-SHA256）、RS256（RSA-SHA256）、ES256（ECDSA-SHA256）和 none（無簽名——在生產環境中禁止使用）。 Payload：又稱為 claims，是一組 JSON 欄位。RFC 7519 定義了 7 個標準註冊聲明：iss（簽發者）、sub（主體，通常是使用者 ID）、aud（受眾）、exp（過期時間）、nbf（生效時間）、iat（簽發時間）和 jti（唯一 ID）。開發者可以在此基礎上加入任何私有欄位，如 userId、role、tenant。 Signature：將 Header 和 Payload 進行 Base64URL 編碼，以句點連接，然後使用 alg 指定的演算法和金鑰進行簽名。HS256 使用 HMAC-SHA256(secret, header_b64 + '.' + payload_b64)；RS256 使用 RSA 私鑰。接收方以相同方式重新計算簽名，檢查兩者是否匹配。 Base64URL vs 標準 Base64：'+' 變為 '-'，'/' 變為 '_'，並去除尾部的 '=' 填充，使結果可以直接放在 URL 路徑和查詢字串中而不觸發百分比編碼。注意 Base64URL 只是一種編碼——它不提供加密或安全性，任何人都可以解碼並讀取 payload。 安全性邊界：JWT 只保證「未被篡改」，不保證「內容是敏感的」。一個常見錯誤是將使用者電話號碼、身分證號碼或密碼雜湊放入 payload，這些內容任何人都能看到。
- 三段式結構：Header.Payload.Signature，每段 Base64URL 編碼；簽名為 HMAC(secret, header_b64 + '.' + payload_b64) 或 RSA(privateKey, 相同輸入)。
- Base64URL 將 '+' 換為 '-'、'/' 換為 '_'，並去除尾部的 '=' 填充，使編碼結果可以直接放在 URL 中（不觸發百分比編碼）。
- 本工具僅在本機驗證 HMAC 系列簽章（HS256/HS384/HS512）。RS256、ES256 等非對稱演算法需要發行方 JWKS 端點提供的公鑰，簽章驗證必須在持有公鑰的伺服器完成——頁面仍可解碼 header 與 payload，但無法驗證簽章。
- 標準聲明：iss（簽發者）、sub（主體）、aud（受眾）、exp（過期 Unix 時間戳，秒）、nbf（生效時間）、iat（簽發時間）、jti（JWT ID，防止重放）。
- alg=none 攻擊：必須嚴格驗證 alg 欄位並拒絕 none 演算法，否則攻擊者可以偽造任何 token；還必須防止演算法替換攻擊（用公鑰作為密鑰驗證 HS256 token）。
- JWT 不是加密的：payload 是明文 Base64URL 編碼，而非加密；對於機密內容應使用 JWE（JSON Web Encryption），但實務上常見做法是將敏感資料保留在後端，透過 sub 欄位引用。
範例
標準 HS256 Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: RFC 7519 第 3 節定義了已註冊 Claim 名稱（sub, iat, exp）已過期 Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Status: 已過期（exp < 目前時間）
備註： exp claim 採用 NumericDate（自 Unix epoch 起算的秒數，依 RFC 7519 第 2 節）含自訂 claims 的使用者資訊 Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
備註： role、tenant 屬於私有 claims，未在 RFC 7519 中定義JWT 實作的安全檢查清單
1. 切勿在 payload 中存放機密 - JWT 只是編碼，並非加密
2. HS256 應使用強度足夠的密鑰（>= 256 位元 / 32 個隨機字元）
3. 多服務系統建議改用 RS256/ES256 進行公鑰驗證
4. 驗證 alg 標頭 - 拒絕 'none' 或非預期的演算法
5. 信任 Token 前先檢查 exp、nbf、iat 時間戳
6. 驗證 aud 是否與你的服務相符，避免 Token 被跨應用重複使用
7. 儲存於 HttpOnly cookie，不要放在 localStorage（防範 XSS）
RFC: RFC 8725（JWT 最佳實踐）涵蓋上述安全考量常見問題
JWT 的三個部分是什麼？
標頭（Header）、負載（Payload）與簽章（Signature），以點號分隔。標頭宣告簽章演算法與 token 類型。負載攜帶聲明，例如 sub、iss、aud、iat、exp 與其他自訂資料。簽章讓驗證端能確認 token 未被竄改。標頭與負載是 Base64URL 編碼的 JSON——只是被簽章，並未加密。
JWT 是加密的嗎？
不是——一般 JWS 格式的 JWT 只簽章不加密。任何攔截到它的人都能將標頭與負載做 Base64URL 解碼，讀取所有聲明，包括使用者 ID、Email 與角色。請把 JWT 內容當作公開資訊；切勿把密碼或機密放進負載。雖然有 JWE（加密的 JWT），但實務上少見得多。
各個標準聲明的意義是什麼？
iss = 簽發者；sub = 主體（通常是使用者 ID）；aud = 受眾（預期接收者）；exp = 到期時間（Unix 秒數）；nbf = 生效時間；iat = 簽發時間；jti = 用於撤銷的 token 唯一 ID。它們由 RFC 7519 定義。自訂聲明可以自由新增——建議廠商專屬的聲明加上字首以避免衝突。
如何驗證 JWT？
讀取 alg 標頭，使用對應的金鑰（HS256 = 共享密鑰，RS256/ES256 = 從簽發端 JWKS 端點取得的公鑰），對編碼後的 header.payload 重新計算簽章再做比對。接著檢查 exp、nbf、iss 與 aud。若 alg 是 'none'、或與您伺服器期待的不同，請拒絕該 token。 本工具僅在本機驗證 HS256/HS384/HS512 共用密鑰簽章；RS256/ES256 的簽章校驗必須在持有公鑰的伺服器完成。
驗證是在我的瀏覽器中進行嗎？
是的。頁面在本機解析 JWT，並使用瀏覽器內執行的 JavaScript HMAC 驗證 HS256/HS384/HS512 簽章。Token 不會送往我們的伺服器，但請記得 JWT 本身就是設計來在 URL 與 HTTP 標頭中傳遞——任何被複製的 JWT 都可能出現在日誌中。
為什麼 alg=none 很危險？
RFC 7519 允許 alg=none 表示未簽章的 token。有漏洞的驗證器可能即使沒有簽章也照單全收，攻擊者就能偽造任意負載。現代函式庫預設拒絕 alg=none；如果您自行實作驗證器，請把預期的演算法寫死，而不是相信標頭傳來的值。
JWT 最大可以多大？
規範上沒有限制，但 JWT 通常會出現在 HTTP 標頭中（Authorization: Bearer ...），許多伺服器把標頭限制在約 8 KB。把太多聲明塞進 JWT 會讓每次請求都變胖。如果您需要大量會話狀態，請改用伺服器端 session，並在 JWT 中只放小小的參考憑證。