JWTデコードツールの使い方
- eyJ で始まる長いトークンを入力欄に貼り付けます。
Authorization: Bearer …のヘッダーごとコピーしたものや、引用符で囲まれたもの、途中で改行されたものも自動で整えます。 - デコードしたヘッダーとペイロードが整形したJSONで表示されます。一番上に有効期限の状態、その下に標準クレームと、日時はお使いのタイムゾーン（日本なら日本時間）での日付と「3 時間後」「16 年前」のような現在からの差が並びます。
- 署名を確かめるには鍵を入力します。HS256・HS384・HS512なら共通のシークレット、RS・PS・ES・EdDSAなら公開鍵を、PEM、JWK、またはJWKS全体で貼り付けます。結果に署名は正しいか署名が正しくないかが表示されます。
JWTの中身
JSON Web Token（RFC 7519）は、base64urlのテキスト3つをドットでつないだものです：ヘッダー.ペイロード.署名。ヘッダーとペイロードはJSONオブジェクトをエンコードしただけで暗号化はされていないので、誰でも読めます。どちらも {" をエンコードした eyJ で始まるのはそのためです。ヘッダーには署名アルゴリズム（alg）、ペイロードにはユーザーやセッションについての情報（クレーム）が入ります。署名は最初の2つの部分を書かれたとおりに計算したものなので、1文字でも変えると検証に失敗します。LINEログインやFirebase Authentication、Amazon CognitoなどのIDトークン、多くのWeb APIのアクセストークンがJWTです。
| クレーム | 名前 | 意味 |
|---|---|---|
iss | 発行者 | トークンを作って署名した者。ログインサーバーのURLが多い |
sub | 主体 | トークンが表す対象。ふつうはユーザーID |
aud | 受信者 | 受け入れるべきサービス。別のAPI向けのトークンは拒否しなければならない |
exp | 有効期限 | この時刻を過ぎたら拒否する |
nbf | 有効開始 | この時刻より前は拒否する |
iat | 発行日時 | トークンが作られた時刻 |
jti | JWT ID | 一意のID。一度使われたトークンを拒否するのに使う |
3つの日時は「NumericDate」で、1970年1月1日（UTC）からの秒数、つまりUnixタイムスタンプと同じ数です。13桁ならミリ秒で書かれていて、よくある不具合としてこのツールが指摘します。表示は端末のタイムゾーンで行うので、日本では日本時間（JST、UTC+9）になります。サーバーは時計のずれとして1〜2分の猶予を認めることが多いですが、ここでの判定には猶予を入れていません。
計算例：RFCのサンプルトークンを読む
JSON Web Signatureの規格RFC 7515は、最初の例（付録A.1）で次のトークンに署名しています。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
ヘッダーをデコードすると { "typ": "JWT", "alg": "HS256" }（HMAC SHA-256のトークン）、ペイロードは { "iss": "joe", "exp": 1300819380, "http://example.com/is_root": true } です。発行者は「joe」、独自のクレームが1つ（http://example.com/is_root）あり、exp の1300819380は2011年3月23日 3:43（日本時間）なので、2026年10月にデコードすると状態は「期限切れ（16 年前）」になります。検証するには、RFCの鍵をJWKとして貼り付けます。
{"kty":"oct","k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"}
署名は正しいと表示されます。ペイロードを1文字変えると、正しくないと表示されます。
入力欄に最初から入っているのは、jwt.ioでおなじみのサンプルトークンで、シークレットは your-256-bit-secret です。このシークレットは19バイトで、RFC 7518がHS256に求める32バイトより短いため、検証するとその点も指摘します。
署名の検証
- HS256・HS384・HS512は、署名と検証に同じシークレットを使います。そのままテキストで入力するか、Base64でエンコードされているなら種類
octのJWKとして貼り付けます。 - RS256・PS256（RSA）とES256（楕円曲線。ES384・ES512はP-384・P-521）は秘密鍵で署名し、対になる公開鍵で検証します。ログインサービスは公開鍵をJWKSとして、
/.well-known/openid-configurationに書かれたjwks_uriで公開しています。そのJSONを貼り付ければ、トークンのkidと同じ鍵を自動で選びます。 - 検証にはブラウザ組み込みのWeb Crypto（HTTPSを支えているのと同じ暗号処理）を使います。鍵は検証にだけ使い、署名、保存、送信はしません。
セキュリティ上の注意
- デコードは検証ではありません。JWTは誰でも読めますし、どんなクレームを書いたトークンでも誰でも作れます。署名、
exp、iss、audをサーバーで確認して初めて信頼できます。 - alg「none」は拒否します。署名のないトークンの印で、受け入れると攻撃者が誰にでもなりすませます（JWTのベストプラクティスRFC 8725）。
- アルゴリズムを固定します。HS256のトークンをRSA公開鍵を「シークレット」として検証するサーバーは、偽のトークンでだまされます（アルゴリズム混同攻撃）。このツールはその組み合わせを受け付けません。
- 本番環境の有効なトークンは、どのWebサイトにも貼り付けないのが安全です。このページはすべて端末内で処理し何も送信しませんが、有効なトークンは期限が切れるまでパスワードと同じ働きをします。できるだけ期限切れかテスト用のトークンを使い、秘密鍵は決して貼り付けないでください。検証に必要なのは公開鍵だけです。
- ペイロードに秘密を入れません。トークンを持つ人なら誰でも読めます。クレーム自体を秘密にする必要があるなら、5つの部分からなる暗号化JWT（JWE）を使います。このツールはJWEを見分けてヘッダーを表示します。
UUID形式の jti を調べるならUUID生成・チェック、ペイロードのJSONを詳しく見るならJSON整形が使えます。
よくある質問
ここにJWTを貼り付けても安全ですか？
トークンはブラウザのJavaScriptでデコード・検証され、サーバーには送られず、ページにも保存されません。ただし有効なトークンは一時的なパスワードと同じなので、どのWebサイトでも、期限切れかテスト用のトークンを使うのが安全な習慣です。信頼できない場所に有効なトークンを貼ってしまったら、ログアウトする（トークンが無効になる場合があります）などの対策をとってください。
シークレットがなくてもJWTをデコードできますか？
できます。ヘッダーとペイロードはbase64urlでエンコードされているだけなので、鍵がなくても読めます。シークレットや公開鍵が必要なのは、トークンが本物で改ざんされていないことを確かめる署名の検証のときだけです。
「署名が正しくない」と表示されるのはなぜですか？
署名後にトークンが変更されたか、署名した鍵ではないかのどちらかです。別の環境（開発・本番）のシークレット、1文字の欠けや余分な文字、鍵のローテーション後の古い公開鍵、先にBase64デコードすべきシークレット（その場合は種類 oct のJWKとして貼り付けます）などが原因になります。
JWT、JWS、JWEの違いは何ですか？
JWS（RFC 7515）は3つの部分からなる署名付きデータ、JWE（RFC 7516）は5つの部分からなる暗号化データです。JWT（RFC 7519）はそのどちらかで運ばれるクレームの集まりで、ほとんどの場合はJWSです。そのため「JWT」と言えばふつう署名付きのトークンを指します。
トークンの有効期限はどこでわかりますか？
有効期限（exp）の行を見てください。お使いのタイムゾーンでの日時と、「2 日後」「3 時間前」のような現在からの差を表示します。exp のないトークンは自然には期限が切れないので、アクセストークンとしては危険です。
最終更新日：2026年10月16日