JWT 解碼器 (頭部、載荷、簽名、過期)

貼上 JWT 即時將頭部和載荷解碼為 JSON。識別標準宣告 (iat、exp、nbf) 並將 Unix 時間戳轉換為 ISO 8601。標記已過期或未生效的 token。

JWT 令牌

在瀏覽器內完成解碼,token 不會透過網路傳輸。

頭部

{
  "alg": "HS256",
  "typ": "JWT"
}

載荷

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1730000000,
  "exp": 4886000000
}

存在簽名: ✓
簽發時間 (iat): 2024-10-27T03:33:20.000Z
過期時間 (exp): 2124-10-30T22:13:20.000Z

運作原理

JWT 的結構

JWT 是用點號連線的三段 Base64url 編碼: header.payload.signature。每段是為 URL 安全傳輸而編碼的 JSON。頭部宣告簽名演算法,載荷攜帶宣告 (主體、過期、自定義資料),簽名讓接收方在持有金鑰時驗證完整性。

本解碼器只讀前兩段。簽名是第三段,但驗證需要金鑰/公鑰——這是單獨操作,本工具不執行。

值得了解的標準宣告

iss (issuer): 簽發者。iat (issued at): 簽發時間,Unix 時間戳。exp (expiry): 失效時間,Unix。nbf (not before): 最早可被接受的時間。sub (subject): token 代表的實體,通常使用者 ID。aud (audience): token 面向的服務,通常服務 URL。

並非全部必需,最小 JWT 常僅包含 sub + iat + exp。自定義宣告是其他任意鍵,與標準宣告並列在載荷中。

解碼 ≠ 驗證

任何人都能解碼 JWT —— 頭部和載荷只是 Base64 編碼的 JSON。所以「不要把秘密放在載荷」: 等同公開資訊。

驗證意味著用金鑰 (HMAC) 或公鑰 (RSA/ECDSA) 校驗簽名。未經驗證,載荷中任何宣告都不可信 —— 攻擊者可偽造任意載荷。

用本工具除錯時檢查 token,生產環境務必用伺服器端 JWT 庫驗證。

常見問題

›可以驗證簽名嗎?

不能 —— 驗證需要金鑰或公鑰,這些不應離開可信環境。請使用伺服器端 JWT 庫 (Node 的 jsonwebtoken、Python 的 PyJWT 等)。

›Token 會上傳嗎?

永不。解碼本地完成,我們沒有接收 token 的伺服器埠。

›為何 token 「無效」?

常見原因: 複製貼上混入/丟失空白、不足三段、某段為非法 Base64url。修剪後重試。

›Base64url 和 Base64 的區別?

Base64url 把 '+' 換 '-'、'/' 換 '_',去掉末尾 '=',讓編碼字串在 URL 和 HTTP 頭中安全傳輸。JWT 始終用 Base64url。

›為何 Unicode 載荷顯示亂碼?

本工具按 UTF-8 解碼 (標準做法)。如載荷用其他編碼,JSON.parse 會失敗。大多數 JWT 簽發者正確使用 UTF-8。

›HS256 安全嗎?

若金鑰足夠長 (≥256 位) 且保密,則安全。常見 HS256 漏洞是弱金鑰和接受 alg='none'。使用 ≥32 字元隨機金鑰,顯式拒絕 'none'。

›為何用 RS256 優於 HS256?

RS256 (非對稱 RSA) 可釋出驗證用公鑰同時保密簽名金鑰。HS256 (對稱 HMAC) 需與每個驗證者共享金鑰。多服務架構下 RS256 更安全。

›可以解碼巨大 token 嗎?

實際上限約 10 MB,超過瀏覽器會變慢。JWT 通常小於 4 KB。如更大,考慮是否在宣告裡塞了過多內容。