JWT デコーダー
トークンのクレームを読み、署名を証明する · このタブ内で動作し、どこにも送信されません
トークン
署名
JWT は暗号化ではなくエンコードされているだけです。このトークンを持っている人は誰でも、鍵なしで上の内容をすべて読めます。それが本物で改ざんされていないと分かるのは、署名を検証したときだけです。
クレーム
トークンパネルにトークンを貼り付けると、そのクレームがここに平易な言葉で並びます。
ヘッダー
ペイロード
JWT デコーダー のしくみ
トークンを 3 つの部分に分け、ヘッダーとペイロードをデコードし、すべてのクレームを平易な言葉で一覧表示する JWT デコーダーです。有効期限、有効開始、発行日時は、エポック秒ではなく実際の日付として表示されます。署名の検証もできます。HS 系なら共有シークレットを、RS・PS・ES 系なら公開鍵を貼り付けると、ブラウザー自身の WebCrypto 上で検証が実行されます。トークンも鍵もアップロードされることはなく、鍵はこのブラウザーに保存すらされません。
トークンを貼り付けると（Bearer 接頭辞はあってもなくても構いません）、3 つの部分に分かれ、それぞれの区切りが色で分かるようになります。ヘッダーとペイロードは JSON にデコードされ、クレームは平易な言葉で改めて一覧表示されます。exp、nbf、iat は実際の日付として、またどれだけ前か・どれだけ先かとしても表示されます。
JWT のデコードは検証ではありません。 最初の 2 つの部分は暗号化ではなく base64url です。トークンを持っている人なら誰でも読めます。だからこそ、トークンは秘密情報を入れる場所ではありません。署名を検証するを有効にして、HS 系なら共有シークレットを、RS・PS・ES 系なら公開鍵を貼り付けると、署名が実際に検証されます — HS256/384/512、RS256/384/512、PS256/384/512、ES256/384/512 に対応し、ブラウザー自身の WebCrypto を使います。
貼り付けた鍵は、このサイトのほかのどの入力とも違う扱いを受けます。localStorage に書き込まれることはなく、再読み込み時に復元されることもありません。トークンも鍵も、どこにもアップロードされません。そもそも、それらを受け取れるサーバーが存在しません。
よくある質問
本物の JWT をこのデコーダーに貼り付けても安全ですか？
はい。トークンはあなた自身のタブ内の JavaScript がデコードしており、送信先となるバックエンドは存在しません。ネットワークを切断してもデコーダーは動き続けます。JWT ではこれが他の多くのデータ以上に重要です。トークンは有効な資格情報であり、サーバーへ送信するサイトに貼り付けることは、そのトークンが与える権限をそのまま渡すことに等しいからです。
デコードできれば、そのトークンは有効なのですか？
いいえ。そしてこの違いは重要です。ヘッダーとペイロードは base64url エンコードであって暗号化ではないため、トークンを持っている人なら誰でも読めます。だからこそ JWT は秘密情報を入れる場所ではありません。正しい鍵で署名を検証して初めて、そのトークンが本物で改ざんされておらず、クレームを信頼してよいと分かります。
検証できる署名アルゴリズムは何ですか？
共有シークレットを使う HS256・HS384・HS512 と、公開鍵を使う RS256/384/512、PS256/384/512、ES256/384/512 です。公開鍵は PEM ブロック、単一の JWK、または JWKS 全体で指定でき、JWKS の場合はトークンの kid が鍵を選びます。検証にはブラウザー内蔵の WebCrypto を使うため、鍵素材がどこかへ送られることはありません。
署名鍵やシークレットは保存されますか？
いいえ。このサイトの他のツールは、再読み込みで作業が失われないように入力内容を localStorage に保存しますが、検証用の鍵は意図的に対象外にしてあります。鍵はメモリ上に保持され、検証に使われ、ページを離れれば消えます。
なぜトークンが期限切れと表示されるのですか？
exp クレームは NumericDate（1970 年からの秒数）で、デコーダーはこれを実際の日付として、また期限からどれだけ経過したかとあわせて表示します。期限切れのトークンは、直前まで動いていた API から突然 401 が返る最も一般的な原因です。未来の nbf クレームも、反対側で同じことを引き起こします。