JWTデコーダー

JSON Web Tokenをブラウザ内でデコード。ヘッダーとペイロード、exp・iat・nbfをお使いのタイムゾーンの日時で表示し、期限切れかどうかもすぐわかります。

JWTをどこにも送らずに中身を確認

JSON Web Tokenを貼り付けると、3つの部分に分けて表示します。ヘッダー（署名に使ったアルゴリズム）、ペイロード（クレーム：ユーザーが誰か、何にアクセスできるか、トークンがいつ期限切れになるか）、そして署名です。JSONは整形されるので、ひと目で読めます。

時刻のクレームは実際の日時に変換されます。exp、iat、nbfをお使いのタイムゾーン、UTC、そして「20分後」「3日前」の形で表示し、トークンがまだ有効か、期限切れか、まだ有効になっていないかを状態欄ですぐに確認できます。

トークンは実際のアカウントへのアクセス権を持つことが多いため、デコードはすべてブラウザ内で行います。トークンがサーバーにアップロード、記録、保存されることはありません。チャットボットや、サーバーに送信するサイトに貼り付けるより安全です。

JWTをデコードする方法

アプリ、Authorizationヘッダー、Cookie、またはブラウザの開発者ツールからトークンをコピーします。
入力欄に貼り付けます。Bearer、引用符、空白、改行は自動で取り除かれます。
概要を確認します：状態、アルゴリズム、発行者、主体、対象者、そして正確な発行日時と有効期限。
コピーボタンで、整形済みのヘッダーやペイロードのJSONをバグ報告やメモに貼り付けられます。

よく使われるクレームの意味

exp（expiration time）：この時刻を過ぎたらトークンは拒否されなければなりません。
iat（issued at）：トークンが作成された時刻。
nbf（not before）：この時刻より前はトークンを受け入れてはいけません。
iss（issuer）：トークンの発行者。多くの場合ログインサーバーのURLです。
sub（subject）：トークンの対象となる人。通常はユーザーIDです。
aud（audience）：トークンを使う想定のアプリやAPI。
algとkid（ヘッダー内）：HS256やRS256などの署名アルゴリズムと、署名に使った鍵のID。

JWTの日時はNumericDate値、つまり1970年1月1日（UTC）からの秒数です。デコーダーが変換するので、別途タイムスタンプ変換ツールを使う必要はありません。

デバッグのヒント

ログイン直後にAPIが401を返す場合は、まずexpとnbfを確認しましょう。サーバーの時計が数分進んでいたり遅れていたりするのはよくある原因で、多くのライブラリは少しの誤差を許容する設定があります。
何万年も先の日時になっている場合、値が秒ではなくミリ秒で書かれています。その場合はデコーダーが警告します。
audとissがAPIの期待する値と合っているか比べましょう。別のアプリや環境（本番ではなくステージング）向けに発行されたトークンは「無効なトークン」エラーのよくある原因です。
ヘッダーのalgがnoneなら、そのトークンは署名されていません。本番環境では絶対に受け入れないでください。

制限と知っておきたいこと

デコードは検証ではありません。誰でも好きなクレームでトークンを作れます。本物だと証明できるのは、サーバー側で正しい鍵を使った署名の検証だけです。このツールは署名を検証しません。
通常のJWTのペイロードはエンコードされているだけで、暗号化されていません。トークンを持つ人なら誰でも読めるので、パスワードや秘密情報をクレームに入れないでください。
暗号化されたトークン（JWE、5つの部分）は鍵がないと読めないため、ヘッダーだけを表示します。
数値はトークン内の表記どおりに表示されるため、長い数値IDが丸められることはありません。

よくある質問

本物のトークンを貼り付けても安全ですか？

はい。デコードはブラウザ内のJavaScriptで行われ、トークンがサーバーに送信されることはありません。それでも有効なトークンはパスワードと同じように扱い、スクリーンショットやチャットで共有せず、期限切れになるのを待ちましょう。

このツールでトークンが有効かどうかわかりますか？

日時をもとに、トークンが期限切れか、まだ有効になっていないかを表示します。署名が本物かどうかはわかりません。それにはサーバーだけが持つべき秘密鍵や公開鍵が必要だからです。

受け取ったばかりのトークンが期限切れと表示されるのはなぜですか？

発行したサーバーの時計を確認し、expがミリ秒ではなく秒になっているか確かめてください。iatも数時間前になっているなら、サーバーの時計がずれている可能性が高いです。