JWTデコーダー
JWT（JSON Web Token）を貼り付けてヘッダー・ペイロードをその場でデコードします。有効期限（exp）の判定付き。署名の検証は行わず秘密鍵の入力も不要です。
主要な登録クレーム（Registered Claims）一覧
| クレーム | 名称 | 説明 |
|---|---|---|
| iss | Issuer（発行者） | トークンを発行した主体を識別する文字列またはURL。 |
| sub | Subject（主題） | トークンが指し示す対象（通常はユーザーID）。 |
| aud | Audience（受信者） | トークンの利用が想定される受信者・APIの識別子。 |
| exp | Expiration Time（有効期限） | これ以降はトークンを受理してはならない時刻（Unix秒）。 |
| nbf | Not Before（有効開始時刻） | これより前はトークンを受理してはならない時刻（Unix秒）。 |
| iat | Issued At（発行時刻） | トークンが発行された時刻（Unix秒）。 |
| jti | JWT ID | トークンを一意に識別するID。リプレイ攻撃対策の重複検知等に使われる。 |
Tips
- 入力したJWTはブラウザ内のJavaScriptのみで処理され、toolbase.cc のサーバーには一切送信されません。トークンに含まれる個人情報や認証情報も外部に漏れる心配はありません。
- JWTはヘッダー・ペイロード・署名の3つがピリオド（.）で区切られたBase64URL文字列です。ヘッダーとペイロードは誰でもデコードできる平文（Base64はエンコードであり暗号化ではありません）のため、パスワードなどの機密情報をペイロードに含めてはいけません。
- 有効期限切れのトークンでAPIリクエストが401エラーになった場合、まずこのツールで
expクレームの値を確認すると原因切り分けが早くなります。 - 署名アルゴリズムは
algヘッダーで確認できます。alg: noneを許容する実装は署名検証を回避される脆弱性（JWTのalg=none攻撃）につながるため、サーバー側では必ず許可アルゴリズムを明示的に制限してください。
よくある質問
はい。JWTのヘッダーとペイロードは暗号化ではなくBase64URLエンコードのため、誰でも中身を読むことができます。パスワードやクレジットカード番号などの機密情報をペイロードに含めるべきではありません。
いいえ、このツールはヘッダー・ペイロードのデコード表示のみを行い、署名の検証は行いません。署名の検証にはトークン発行者だけが知る秘密鍵（またはRSA/EC公開鍵）が必要で、これをブラウザに入力すること自体がセキュリティ上望ましくないためです。
多くのAPI・認証サーバーは
exp クレームが現在時刻より過去のJWTを拒否し、401 Unauthorized 等のエラーを返します。トークンの再取得（リフレッシュトークンによる再発行など）が必要です。
余談ですが ― JWTが「ステートレス認証」を実現する仕組み
JWT（JSON Web Token）は2015年にIETFのRFC 7519として標準化されました。従来のセッションベース認証ではサーバー側にセッションIDとユーザー情報の対応表を保持する必要がありましたが、JWTはユーザー情報そのものをトークン内に埋め込み、署名で改ざんを検知する方式を採用しています。これによりサーバーはセッションストアを持たずに認証状態を検証できる「ステートレス認証」が可能になり、複数サーバーにまたがる分散システムやマイクロサービス間の認証で広く採用されています。
JWTの構造は「ヘッダー.ペイロード.署名」という3部構成で、それぞれがBase64URLエンコードされてピリオドで連結されます。重要なのは、ヘッダーとペイロードは暗号化ではなく単なるエンコードであるという点です。誰でもデコードして中身を読めるため、JWTは「改ざんされていないことを保証する」ものであって「内容を秘匿する」ものではありません。機密情報を含めたい場合は、暗号化を追加したJWE（JSON Web Encryption）という別の仕様を使う必要があります。
署名方式には大きく分けて、送信者と受信者が同じ秘密鍵を共有するHMAC方式（HS256等）と、秘密鍵で署名し公開鍵で検証する公開鍵暗号方式（RS256・ES256等）があります。OAuth 2.0やOpenID Connectのアクセストークン・IDトークンとしてJWTが採用されて以降、Webの認証基盤における事実上の標準フォーマットとなりました。