JWT デコーダー
JSON Web Token を貼り付けると、ヘッダーとペイロードを読み、有効期限を確認し、各クレームの意味を理解できます。トークンがブラウザの外に出ることはありません。
ブラウザ内で動作登録不要アップロードなし
デコードは検証ではありません。JWT のヘッダーとペイロードは base64url でエンコードされているだけなので、誰でも読めます。このツールはトークンが主張している内容を表示するだけで、トークンが本物であることは証明しません。署名は必ずサーバー側で検証してください。
ヘッダー
ペイロード
クレームの説明
署名を検証（任意、HS256/HS384/HS512）
入力したシークレットで HMAC 署名をチェックします（ブラウザの Web Crypto API を使用）。シークレットがこのページの外に出ることはありません。RSA/ECDSA のトークンは発行者の公開鍵が必要なため、ここでは検証しません。
JWT デコーダーの使い方
- エンコードされたトークンの欄にトークンを貼り付けます。Authorization ヘッダー由来の先頭の
Bearerは無視されます。 - ヘッダーとペイロードが即座にデコードされ、整形された JSON で表示されます。
- クレームの説明の表を確認します。
exp、iat、nbfは日時に変換され、「あと〜で期限切れ」「〜前に期限切れ」と表示されます。 - ステータスバーで有効期限の問題を、警告で
alg: noneのような危険な設定を確認します。 - 必要に応じて共有シークレットを入力し、HS256、HS384、HS512 の署名をローカルで検証します。
JWT の中身は？
JSON Web Token（RFC 7519）は、3 つの base64url 文字列をドットでつないだものです：header.payload.signature。ヘッダーは署名アルゴリズム（alg）とトークンの種類を示します。ペイロードには、ユーザーが誰か、トークンがいつ期限切れになるかといったクレームが入ります。署名は、最初の 2 つの部分からシークレットまたは秘密鍵を使って計算されます。
デコードは検証ではない
ヘッダーとペイロードはエンコードされているだけで暗号化されていないため、トークンを持っている人なら誰でも読めます。だからこそ、JWT のペイロードにパスワードや秘密情報を入れてはいけません。デコードでわかるのはトークンが何を主張しているかです。署名の検証は、通常 API サーバー上で jose や PyJWT などのライブラリを使って行い、誰が発行したか、改ざんされていないかを証明します。サーバーは exp、nbf、iss、aud もチェックし、想定外のアルゴリズムを拒否する必要があります。
登録済みクレーム早見表
| クレーム | 意味 |
|---|---|
iss | 発行者（Issuer）：トークンを作成・署名した者 |
sub | 主体（Subject）：通常はユーザー ID |
aud | 対象者（Audience）：トークンの宛先となる API |
exp | 有効期限（Unix エポックからの秒数） |
nbf | この時刻より前は無効 |
iat | 発行日時 |
jti | トークンの一意な ID。失効リストに便利 |
「token expired」エラーのデバッグ
発行されたばかりに見えるトークンを API が拒否する場合は、exp と nbf をサーバーの時計と比較してください。マシン間のわずかな時刻のずれはよくあるため、多くのライブラリは 30〜60 秒の猶予を設けています。また、exp が秒単位になっているかも確認しましょう。ミリ秒の値はよくあるバグで、有効期限が数千年先になってしまいます。
よくある質問
本番の JWT をここに貼り付けても安全ですか？
このツールは JWT の署名を検証しますか？
トークンが期限切れと表示されるのはなぜですか？
exp クレームが、お使いのコンピューターの時計と比べて過去になっています。新しいトークンを取得するか、リフレッシュトークンで更新してください。時刻がおかしい場合は、時刻のずれや、ミリ秒で書かれた exp の値を確認してください。JWT、JWS、JWE の違いは何ですか？
alg が「none」だと危険なのはなぜですか？
alg: none を拒否し、想定している特定のアルゴリズムだけを受け付けるべきです。