JWT デコーダー

JWT デコーダーの使い方

1. 1テキストを入力またはペーストします
2. 2「変換する」ボタンをクリックします
3. 3結果を確認してコピーします

良いJWT デコーダーの判断基準

API のデバッグや認証エラーの調査でトークンの中身を確認したい時は、本ツールでデコードした結果を下の判断基準と照らして読み解いてください。大前提として、デコードは「中身を読む」操作であって「正しいトークンだと確かめる」操作ではありません。

• デコードと署名検証は別だと理解しているか

  デコードで中身が読めることと、そのトークンが改ざんされていないことは別問題です。トークンの正当性はサーバー側の署名検証で確認するものなので、デコード結果だけを根拠に信用しないでください。

• exp（有効期限）を確認したか

  認証エラーの調査では、まず有効期限が切れていないかを見ます。期限切れならトークンの再取得で解決することが多く、それ以外の原因を調べる前に切り分けられます。

• 発行元・宛先・ユーザーは想定通りか

  iss（発行者）・aud（宛先）・sub（ユーザー識別子）が、自分のシステムで想定している値と一致するかを確認します。別環境のトークンを取り違えているケースはここで見つかります。

• Payload に機密情報が入っていないか

  Payload はデコードすれば誰でも読めます。自分が設計する側なら、パスワードなどの秘匿すべき情報を Payload に入れていないかを、このツールで実際にデコードして確かめます。

• alg（署名アルゴリズム）を確認したか

  Header の alg が自分のシステムで想定しているものと一致するかを見ます。署名なしを意味する値が本番のトークンに現れるのは異常なので、検証側の設定を見直します。詳細な扱いは利用しているライブラリのドキュメントで確認してください。

• トークンの貼り付け先は安全か

  本番のトークンは、それ自体が認証に使える機密情報です。貼り付け先のツールがサーバーに送信しない（ブラウザ内で完結する）ことを確認してから使います。

ありがちな失敗例（NG → 改善）

eyJ で始まる文字列の中身が読めないとき

JWT（JSON Web Token）は API 認証・OAuth・OpenID Connect で標準で使われているトークン形式です。ただ、`eyJhbGciOiJIUzI1NiI...` のような文字列だけ見ても中身は分かりません。jwt.io のようなオンラインデコーダーが定番ですが、英語 UI で「本番環境のトークンを外国のサーバーに貼り付けて大丈夫か」とセキュリティ判断に迷う場面もあります。本ツールは Header と Payload を日本語 UI でデコードし、Signature はそのまま表示 + exp / iat / nbf などの時刻クレームを JST に自動変換 + 有効期限判定。完全にブラウザ内で完結し、サーバー送信は一切行いません。

編集部が4本のトークンを貼りながら通信を見張った範囲でも、処理中に外部へ送る通信は1件も発生しませんでした。

JWT の 3 セグメント構造

JWT は `header.payload.signature` の 3 部分をピリオドで連結した文字列です。

【Header】署名アルゴリズム（alg）とタイプ（typ）を含む JSON。例: `{"alg":"HS256","typ":"JWT"}`

【Payload】クレーム（claims）と呼ばれるトークン本体の JSON。標準クレーム + 独自クレームを格納。

【Signature】Header + Payload を秘密鍵で署名した結果。改ざん検知に使用。

各セグメントは Base64URL エンコード（標準 Base64 から +/= を -_ に置換）されて連結されます。本ツールの Signature 欄に出るのは、3つ目の区切りより後ろの文字列をそのまま並べたものです。

主要クレーム（RFC 7519）

【iss】Issuer（発行者）= 認証サーバー URL 等 【sub】Subject（主体）= ユーザー ID 等 【aud】Audience（受信者）= API クライアント ID 等 【exp】Expiration Time = 有効期限（Unix 秒） 【nbf】Not Before = 有効開始時刻（Unix 秒） 【iat】Issued At = 発行時刻（Unix 秒） 【jti】JWT ID = トークン一意 ID

独自クレームは `name` / `email` / `role` / `scope` 等が一般的（RFC 8693 / OAuth 2.0 で予約語あり）。

本ツールが日時に読み替えて別表に出すのは exp・iat・nbf と auth_time の4つです。この4つ以外の数値は、Payload 欄にそのままの数字で表示されます。

401 の切り分けや OIDC 連携でトークンの中身を見る作業

【1. API デバッグ】Authorization ヘッダの Bearer トークンが正しく送信されているか確認 + ユーザー ID / 権限 / 発行時刻を即チェック。

【2. 期限切れ判定】テストで「401 Unauthorized」が出た時、トークンの exp が過ぎていないかをワンクリック確認。

【3. OAuth / OIDC 連携検証】Auth0 / Cognito / Firebase / Supabase 等が発行する ID Token の中身を見て、scope / aud / iss が想定通りか確認。

【4. JWT 学習】Udemy / Zenn / Qiita で JWT を学ぶ際に、サンプルトークンの中身をビジュアルに理解できる。

【5. インシデント調査】不正トークン疑いの解析時、iss / sub / iat / exp を即可視化して攻撃シナリオを判別。

1番目に関して補足すると、ヘッダーからコピーした文字列の先頭に Bearer と空白が付いたままでも、その語は自動で取り除かれてから読み込まれます（処理を確認しました）。貼り直しの手間はかかりません。

署名アルゴリズム別の特徴

【HS256】HMAC + SHA-256。共有秘密鍵方式（対称鍵）。検証側も発行側と同じ鍵を持つ必要あり。マイクロサービス内通信向き。

【RS256】RSA + SHA-256。公開鍵方式（非対称鍵）。発行者のみ秘密鍵を持ち、検証者は公開鍵で署名確認。OAuth / OIDC で標準。

【ES256】楕円曲線（ECDSA + P-256）+ SHA-256。RS256 と同じ公開鍵方式だが、鍵サイズが小さく署名も短い。WebAuthn / FIDO2 でも採用。

【none】署名なし。脆弱性事故が多発したため本番禁止。jwt.io / 各種ライブラリで明示的に拒否設定すべき。

画面上部には、貼ったトークンの alg がそのまま表示されます。表示されるのは Header に書かれている値であって、その方式で正しく署名されていることの確認ではありません。この違いは次の項目で実際に確かめています。

期限切れ・exp なし・2セグメントの3本をデコードした実処理結果

編集部で4本の JWT を作って貼り、画面に出た文字をそのまま記録しました。

1本目は、有効期限を過去に設定した HS256 のトークンです。Header 欄には {"alg": "HS256", "typ": "JWT"} の2項目が2スペース字下げで表示され、Payload 欄には sub・name・iat・exp の4項目が同じ形で並びました。上部の「有効期限」欄は赤い表示に変わり、「期限切れ（12 分前に失効）」と出ました。exp と iat は Payload 欄の数字に加えて、下の表に日本時間の日時と「〜分前」「〜分後」という相対時間が並ぶ形でも表示されます。何秒ずれているかを自分で計算する必要はありません。

2本目は、exp を入れずに作ったトークンです。「exp（有効期限）が設定されていません」と表示され、色は付きませんでした。期限が無いこと自体をエラーにはしない作りです。

3本目は、ピリオドが1つしかない（Header と Payload だけの）文字列です。「JWT は 3 セグメント（header.payload.signature）必要です。現在 2 セグメント」というエラーが出て、中身は表示されませんでした。セグメントの数だけは、デコードの前に数えています。

署名を壊した JWT が警告なしで表示された実処理結果

4本目は、正しく作った HS256 のトークンの、署名部分の末尾5文字だけを別の文字に置き換えたものです。

結果は、エラーにならず、Header も Payload も1本目と同じように表示され続けました。壊れていることを知らせる警告も、色の変化もありません。

これは不具合ではなく、そういう設計です。Signature 欄の下には「本ツールは署名検証は行いません（HS256 は共有秘密鍵、RS256 / ES256 は公開鍵が必要）。改ざんチェックはサーバー側で行ってください。」という注記が常に出ています。署名を検証するには鍵が要り、その鍵をブラウザに置くわけにいかないためです。

分かったクセは、表示の判断材料が Payload に書かれた内容だけだということです。exp が過去なら「期限切れ」、nbf が未来なら黄色の表示、exp が無ければ色なし。いずれも「本物かどうか」ではなく「そう書いてあるかどうか」を見ています。

弱点は、この注記を読み飛ばすと「表示された＝正しいトークン」と受け取れてしまう点です。今回試した4本で見えた範囲での話で、どんなトークンでも同じ表示になる保証ではありません。RS256 や ES256 のように公開鍵を使う形式のトークンは今回用意できておらず、その表示は確かめられていません。

他のツールとの違い

jwt.io（auth0 製）は英語 UI で世界標準ですが、本番トークンを外国サーバーに送るかの判断が必要です。本ツールは:

【完全クライアントサイド】サーバー送信ゼロ・ログ記録なし・本番の機密トークンも外部に出ない 【日本語 UI】alg / typ / exp 等の用語に日本語ラベル併記 【時刻クレーム自動変換】exp / iat / nbf などの時刻クレームの Unix 秒を JST 日時 + 「〇分前 / 〇時間後」相対時間に自動表示 【有効期限即判定】緑（有効）/ 赤（期限切れ）/ 黄（nbf 未到来）でカラー表示 【無料・登録不要・広告なし】

本ツールが判定しているのは、トークンに書かれている内容です。そのトークンが改ざんされていないかどうかは、鍵を持つサーバー側の検証結果でしか分かりません。

本番の認証や他人のトークンに使わない線引きと、貼る前に見る3点

1つ目: JWT は「暗号化」ではなく「署名」 → Payload は Base64URL デコードすれば誰でも読める。パスワード等の機密情報を Payload に入れてはいけない（暗号化したい場合は JWE を使う）。

2つ目: alg = none を許可してしまう → 攻撃者が任意の Payload で署名なし JWT を作れる。ライブラリ設定で必ず許可アルゴリズムを明示。

3つ目: exp を見ずに使う → サーバー側で必ず exp 検証。クライアント側のチェックは UX 向上目的のみ。

4つ目: HS256 の秘密鍵をフロントエンドに置く → 即漏洩。HS256 はバックエンド完結用。フロントから検証するなら RS256 / ES256 の公開鍵方式。

5つ目: アルゴリズム confusion 攻撃 → RS256 想定のサーバーに HS256 + 公開鍵を秘密鍵として送って署名偽造する古典脆弱性。ライブラリの最新バージョン使用 + alg を allowlist で固定。

向かない用途は2つです。1つは、他人から受け取ったトークンが本物かを確かめる目的。本ツールは中身を読むだけで、改ざんの有無は判定しません。もう1つは、本番の認証を通すかどうかの判断に使うことです。期限も権限も、サーバー側が鍵を使って検証した結果だけが根拠になります。

貼る前・使う前に人が見るのは3点です。1点目は、そのトークンを画面に出してよいか。Payload は誰でも読める前提のデータですが、ユーザー ID や権限はそのまま映ります。2点目は、alg 欄が想定したアルゴリズムかどうか。none や、想定と違う方式が出たら、そのトークン自体を疑います。3点目は、有効期限欄が「期限切れ」なのか「exp（有効期限）が設定されていません」なのかの区別です。前者は期限を過ぎたトークン、後者は期限をトークンに持たせていない設計で、意味がまったく違います。