JWT 解析器

JWT 解碼器會把令牌中可見的部分還原成可讀 JSON，讓你不必手動拆分 Base64URL 片段就能檢查認證資料。它最適合排查登入失敗、介面 401/403、環境串錯、權限範圍不一致、過期時間異常等問題；但它本身並不負責證明這個令牌可信。

工具邊界

本頁目前能力限定為解碼與檢查：不會要求輸入 secret 或公鑰，不會驗證 signature，也不會產生或重新簽發 JWT。

JWT 是三段 Base64URL 內容，不是一團加密密文

常見簽名 JWT 寫作 `header.payload.signature`。其中 header 和 payload 通常是經過 Base64URL 編碼的 JSON；Base64URL 使用適合 URL 的字元集，並可能省略填充字元。拿到令牌的人都能解開這兩段 JSON，所以「能讀到 payload」是 JWT 的常規屬性，不能把它誤解成已經完成授權。

• Header：描述令牌類型、簽章演算法等中繼資料。
• Payload：承載關於主體、簽發者、受眾、時間限制、權限範圍或業務事實的 claims。
• Signature：用於保護編碼後的 header 與 payload，但只有使用正確密鑰材料驗證後才有信任意義。

需要優先識別的註冊宣告

如何使用這個工具

1. 粘贴完整的三段式 JWT，让工作区同时解析 header 和 payload。
2. 先檢查算法、issuer、audience 以及 exp、nbf 时间，再判断下一步需要验证什么。
3. 把解码结果只当作可读檢查视圖，签名和關鍵声明仍要回到真实认证系統里验证。

解碼後應按什麼順序閱讀

解碼 JWT 時最好保持固定閱讀順序，這樣能把格式問題和真實認證失敗分開。先確認令牌段數是否正常，再看演算法和類型，再檢查影響簽發方、受眾、時間、主體與權限範圍的宣告。

1. 先看 header 裡的 `typ` 和 `alg`，再判斷 payload。
2. 把時間類 claims 與日誌系統使用的時區放在一起核對。
3. 把解碼出的自訂 claims 當作排查證據，而不是直接放行權限的依據。

JWT 解析器 範例

這個 JWT 解析器 示例使用有代表性的由 Base64URL header、payload 和 signature 组成的 JWT 字元串，展示產生后的可阅读的令牌 header 與 payload JSON，便于你先確認三段式令牌結構、Base64URL 解码、exp 與 nbf 时间、issuer、audience，以及解码不等于验签，再把同样設定用于真实輸入。

範例輸入

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature

預期輸出

{
  "alg": "HS256"
}
{
  "sub": "123"
}

Header 與 Payload 解碼範例

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

Payload:
{
  "sub": "toolkit-user",
  "name": "ToolKit Online",
  "iat": 1700000000
}

Signature:
存在，但本解碼器不會驗證它

僅解碼檢查的安全偽程式碼

parts = token.split(".")
if parts.length < 2:
  rejectAsMalformed()

header = parseJson(base64UrlDecode(parts[0]))
payload = parseJson(base64UrlDecode(parts[1]))
signatureSegment = parts[2] || ""

show(header, payload, signatureSegment)
warn("解碼結果不等於簽章驗證")

JWT 解碼器最適合哪些排查場景

JWT 解碼器本質上是認證與授權排障中的視覺化工具。它讓開發、支援、介面負責人先圍繞「令牌裡寫了什麼」達成共識，再繼續檢查服務端驗簽、密鑰設定或業務授權規則。

• 確認前端是否把測試環境 token 發到了生產介面，或反過來。
• 當一個 API 接受令牌、另一個 API 拒絕時，對比 `aud`、`iss` 和 scope 類宣告。
• 排查突然登入失敗、刷新失敗時，檢查 `exp`、`nbf` 或伺服器時鐘偏差是否相關。

常見使用場景

JWT 解析器 最適合用在由 Base64URL header、payload 和 signature 组成的 JWT 字元串需要快速变成可阅读的令牌 header 與 payload JSON的場景，尤其是登录排查、API 授权核对、环境不一致、权限声明和支持调查。

• 用于在本地解码 JWT header 和 payload 声明，服务于登录排查、API 授权核对、环境不一致、权限声明和支持调查。
• 處理重要輸入前，可先用示例流程確認三段式令牌結構、Base64URL 解码、exp 與 nbf 时间、issuer、audience，以及解码不等于验签。
• 当结果符合目標流程后，再複製或下载可阅读的令牌 header 與 payload JSON。

解码器真正適合帮你檢查什么

JWT 解码页最有价值的場景，是登录排查、接口联调、环境验证和声明欄位核对。它能让你很快確認令牌里有没有预期的用户标识、角色、受众、过期时间和算法声明，從而快速缩小问题范围。但只要问题已经触及“這個令牌能不能被信任”，判断权就必须交回真实认证链路，而不是停留在頁面上看到的可读内容。

• 解码视圖適合檢查声明是否存在，不適合绕过服务器端真正的验证規則。
• 排查认证失败时，最好把 `exp`、`nbf`、`iss`、`aud` 和算法声明一起看，而不是只盯着某一個欄位。
• 还要记住 JWT 使用的是 Base64URL 变体，它與标准 Base64 在字元集和填充處理上可能略有不同。

解碼絕對不等於驗簽

這是 JWT 工具頁裡最關鍵的邊界。你把 token 解析開，只說明你看懂了它長什麼樣，並不說明這個 token 來自可信簽發者，也不說明簽章一定正確、更不說明它現在仍然有效。真正的驗簽和接受邏輯，必須回到認證系統裡完成。

• 排查問題時，至少要結合 `exp`、`nbf`、`iss`、`aud` 以及業務自訂 claims 一起看。
• 複製生產環境 token 時也要謹慎，因為 payload 裡可能含有使用者、工作階段或權限範圍資訊。

演算法欄位只是上下文，不是本機可信結論

`HS256`、`RS256`、`ES256` 這類值只能說明令牌聲稱使用了哪種演算法。真實驗證器仍必須強制演算法白名單、選擇正確的 secret 或公鑰、拒絕不符合預期的 `alg` 值，並在驗簽後繼續校驗必要 claims。

• 不要因為 header 裡寫了某個演算法，就直接信任該演算法。
• 不要把密碼、密鑰、私鑰或敏感客戶資料放進 payload，因為解碼後的 payload 是可讀的。
• 真實產品中應按需要配合短有效期、HTTPS、密鑰輪換、服務端撤銷或刷新令牌機制。

幾種 JWT 檢查動作的差異

JWT 與相鄰令牌形態對比

使用注意

• 複用可阅读的令牌 header 與 payload JSON前，先檢查三段式令牌結構、Base64URL 解码、exp 與 nbf 时间、issuer、audience，以及解码不等于验签。
• 只有真实认证系統完成签名和必要声明校验后，解码出的 JWT 才能被信任。
• 当结果会影响生产工作或客户可见内容时，應保留原始由 Base64URL header、payload 和 signature 组成的 JWT 字元串以便回退和核对。

JWT 解析器 參考說明

JWT 解析器 會解釋 header、payload、signature、過期時間，以及解碼和驗簽不是一回事。

• JWT 通常由三段 Base64URL 內容組成：header、payload 和 signature。
• 其中 header 和 payload 本質上只是經過 Base64URL 編碼的 JSON；signature 則是對 `header.payload` 這段 ASCII 文字計算出的簽章結果。
• 簽章演算法既可能是 HS256 這類對稱演算法，也可能是 RS256/ES256 這類非對稱演算法，但僅靠解碼永遠不能證明令牌可信。
• 實際認證中還需要檢查 exp、nbf、iss、aud 和簽章驗證。

參考資料

• RFC 7519: JSON Web Token (JWT)
• RFC 7515: JSON Web Signature (JWS)
• RFC 8725: JSON Web Token Best Current Practices