JWT 解碼工具

JSON Web Token 看起來像一團無法辨識的亂碼，但其實只是三段以英文句點串接的 Base64URL 編碼內容：header、payload 與 signature。解碼 header 和 payload 完全稱不上加密——任何拿到這個權杖的人都能讀出裡面的 claim，這也正是敏感資料絕對不該塞進 JWT payload 的原因。真正的問題在於，人們需要檢查的權杖很少是可以隨意丟棄的測試資料。它們往往是正式環境應用程式的即時 session token、API 存取權杖，或是除錯時直接從瀏覽器開發者工具裡複製出來的登入 cookie——是真實的憑證，落入錯誤的人手上就代表真實的存取權限。把它貼到一個來路不明的網站，等於把你的 session 交給一個你完全不了解的伺服器。

這個工具絕對不會這麼做。header 與 payload 是在你貼上權杖的當下，用瀏覽器裡的純 JavaScript 解碼完成——依句點切開、做 Base64URL 解碼、再解析成 JSON——過程中沒有任何一個位元組被傳送出去。簽章驗證的原理也一樣，使用的是所有現代瀏覽器內建的 Web Crypto API（`SubtleCrypto`）：HMAC 演算法（HS256、HS384、HS512）會用你輸入的密鑰來驗證，RSA 演算法（RS256、RS384、RS512）則用你貼上、PEM 格式的公鑰來驗證。無論是密鑰本身還是驗證動作，都只停留在這個分頁裡；重新整理頁面之後，權杖、密鑰、金鑰通通會被清空，不留任何痕跡。

貼上一個權杖，就能看到 header 與 payload 以易讀的格式呈現，同時附上標準 `exp`、`iat`、`nbf` claim 轉換成人看得懂的日期時間，如果權杖的 `exp` 已經過了，還會清楚標示「已過期」的徽章——很適合用來確認「我被登出了」這類回報，是不是其實只是權杖過期而已。如果演算法是 HS256/384/512 或 RS256/384/512，輸入對應的密鑰或公鑰，就能檢查這個簽章究竟是真的，還是被動過手腳。至於這個範圍以外的演算法（例如 ES256，或完全沒有簽章的 `none`），仍然能正常解碼，只是工具不會假裝提供驗證結果。對本機開發來說，可編輯的 header/payload 欄位讓你能調整某個 claim——例如改一下使用者 ID 或角色——再用測試伺服器使用的同一組 HS256 密鑰重新簽署，這是測試授權邏輯時，不必真的跑一整套登入流程的常見做法。

由於 JWT 的 payload 解碼之後就是單純、可讀的 JSON，如果你需要更仔細檢視某個巢狀很深的 claim，搭配 JSON 格式化與驗證工具會非常順手。有一點安全提醒值得再三強調：因為解碼本身完全不需要任何密鑰，所以只要檢查完畢，就該把任何權杖當成敏感資訊看待；如果不確定它在抵達這裡之前還被貼到過哪些地方，而它原本又只該是短效期的憑證，建議儘快輪換相關的認證資訊。