JWT デバッガー

JWTデコード・署名検証

JWTトークンをブラウザ上で安全にデコード・検証。ヘッダーやクレームの解析、HS256・RS256・ES256の暗号署名検証、有効期限チェックを完全ローカルで実行します。

プリセット:
エンコード済み JWT トークン
ヘッダー (JOSE)(74B)
.
ペイロード (クレーム)(248B)
.
暗号署名(342B)
PKCS#1 / X.509 SPKI
クロックスキュー許容値:
60s
Length: 666 charsSegments: 3/3
ヘッダー (JOSE) • ペイロード (クレーム) • 暗号署名
Expiration (exp): 244d ago
デコード済みヘッダー (JOSE)alg: RS256
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth0-key-2026-prod"
}
デコード済みペイロード (クレーム)6 registered & custom claims
{
  "iss": "https://auth.example.com/",
  "sub": "auth0|64f1a2b3c4d5e6f7",
  "aud": "https://api.example.com/v2/",
  "iat": 1772500000,
  "exp": 1772586400,
  "scope": "read:profile write:reports openid email"
}
iss (Issuer): https://auth.example.com/
sub (Subject): auth0|64f1a2b3c4d5e6f7
aud (Audience): "https://api.example.com/v2/"
iat (Issued At): 245d ago
Status:UNVERIFIED|Time: 0ms
トークンサイズ666 B
アルゴリズムRS256
有効期限トークン期限切れ
セキュリティ健全性85/100
署名状態シークレットまたはPEMを入力して検証
クレーム総数6 Claims

完全クライアントサイド処理

Web Crypto APIを活用し、ブラウザ内メモリでのみ高速に検証処理を実行します。

サーバー送信ゼロのプライバシー保護

入力されたトークンやクレーム、秘密鍵は外部サーバーへ一切送信されずローカルで完結します。

実環境対応のエクスポート

検証済みの正規化JSONやトークン文字列を本番環境へ即座に適用可能です。

ToolsAA•100% クライアント実行・完全プライベートWeb開発ツール
技術リファレンス・アーキテクチャガイド

JWT Debugger Tool (Decode & Verify) ガイド — 技術リファレンス

JWT（JSON Web Token）をブラウザ上で安全にデバッグ・検証。ヘッダーおよびペイロードのクレーム解読、HS256・RS256・ES256署名の暗号検証、有効期限のローカル監査をサーバー送信なしで高速実行します。

JWT Debugger Tool (Decode & Verify) ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
JWT Debugger Tool (Decode & Verify) ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

JOSEヘッダー（Javascript Object Signing and Encryption）JSONオブジェクト（RFC 7515 JWS仕様）

暗号化アルゴリズム（'alg': HS256、RS256、ES256）およびトークンタイプ（'typ': 'JWT'）を定義します。アルゴリズム混同攻撃（Algorithm Confusion Attacks）を阻止するため、検証側で厳格なアルゴリズムのホワイトリスト（許可リスト）を適用する必要があります。正規表現バックトラッキング（ReDoS）を排除し、O(n) の線形走査時間で安全に解析されます。

初期値: {"alg":"HS256","typ":"JWT"}
JWTクレームペイロード（RFC 7519 クレームセット）JSONオブジェクト（RFC 7519仕様）

アイデンティティのアサーション、エンティティのメタデータ、およびアクセススコープを格納します。標準の登録済みクレームには 'sub'（サブジェクト / 主体）、'iss'（発行者）、'aud'（対象受信者）、'iat'（発行時刻）、'exp'（POSIXエポック秒単位の有効期限）が含まれます。ブラウザのローカル Web Crypto API サンドボックスにより、外部ネットワークへのデータ送信ゼロかつ O(n) の計算量でクレームを安全にデコードします。

初期値: {"sub":"user_123","iat":1772500000,"exp":1772503600}
JWSコンパクト署名（デジタル署名・MAC）Base64URLバイナリ暗号ダイジェスト

秘密鍵または共有シークレットを用いて「Base64URL(Header) + "." + Base64URL(Payload)」に署名することで生成される暗号ダイジェスト。タイミング攻撃（Timing Side-Channel Attacks）を防ぐため、定数時間比較（Constant-Time Comparison）によりメッセージの真正性とペイロードの完全性を暗号学的に検証します。

初期値: Base64URLエンコードされたHMACまたはRSA署名
HMAC共有シークレット / 公開PEM鍵暗号鍵マテリアル（SPKI PEM / 生シークレット文字列）

署名の検証に使用される暗号鍵。オフライン辞書攻撃や総当たり攻撃（ブルートフォース）を防ぐため、HS256では最低256ビット（32バイト）のエントロピーを持つシークレットが必要です。RS256では2048ビットまたは4096ビットのRSA SPKI PEM公開鍵が必要となり、ES256では Web Crypto API の crypto.subtle.importKey() 経由でインポートされた P-256（secp256r1）楕円曲線公開鍵を使用します。

初期値: your-256-bit-secret
クロックスキュー許容範囲（リーウェイ / 時刻誤差許容秒数）時間オフセット境界値（秒）

'exp'（有効期限）および 'nbf'（有効化日時）クレームの検証時、認証発行サーバーとリソース検証サーバー間の NTP（Network Time Protocol）同期ドリフトやクロックのズレを吸収するための許容時間誤差（標準推奨値: 30〜120秒、ベンチマーク既定値: 60秒）です。

初期値: 60秒

現場のベストプラクティス・実践Tips

クライアント側でのJWTデコードのみに依存しない（リソースサーバーでの署名検証が必須）

フロントエンドのJavaScriptでBase64URLデコードを実行すれば、UIパーソナライズ（ユーザー名表示など）のためにクレームを抽出できますが、その真正性は一切保証されません。悪意ある攻撃者は、'role: admin' などのペイロードクレームを数秒で改ざん可能です。本番環境のAPIゲートウェイやバックエンドサーバーは、リクエストを認可する前に、信頼できるシークレットまたは公開鍵を用いてJWS署名を数学的に必ず検証しなければなりません。

'alg: none' による暗号署名バイパス攻撃の防御策（RFC 8725 第3.1項）

RFC 7519では、セキュリティ保護を必要としないコンテキストのために 'alg: none' トークンが仕様として認められています。しかし、脆弱な検証ライブラリでは署名ブロックが空の 'alg: none' トークンを検証成功として誤認し、攻撃者による任意のクレーム偽造を許してしまいます。JWT検証ミドルウェアには常に明示的なアルゴリズム許可リスト（例: algorithms: ['RS256']）を設定し、'alg' が 'none' または期待される暗号スイートと不一致のトークンは即座に拒絶してください。

HS256共有鍵には256ビット以上のエントロピーを強制（RFC 7518 第3.2項）

対称鍵暗号であるHMAC署名の強度は、共有シークレットの堅牢性に完全に依存します。HS256のシークレットが一般的な単語であったり、32バイト（256ビット）未満の短い文字列である場合、傍受されたトークンから hashcat などのオフライン総当たり攻撃ツールによってわずか数秒で秘密鍵が特定されます。'crypto.getRandomValues(new Uint8Array(32))' や CSPRNG（暗号論的擬似乱数生成器）を用いて生成された、暗号学的に安全な256ビット以上のランダムな鍵を使用してください。

対称鍵・非対称鍵間の鍵混同攻撃（Key Confusion Attack）の緩和策（RFC 8725 第3.2項）

アルゴリズム混同攻撃では、攻撃者がRS256トークンのヘッダーを 'HS256' に書き換え、サーバーの公開RSA鍵をHMAC共有鍵として悪用して署名を作成します。バックエンドの検証ライブラリが厳密な鍵タイプ検証を行わずにアルゴリズムを動的評価している場合、この偽造トークンが有効と判定されてしまいます。これを防ぐには、エンドポイントごとに期待するアルゴリズムを厳格に固定（ピニング）し、HMAC鍵ストアとRSA鍵ストアを物理的・論理的に完全に分離してください。

JWTペイロードは「エンコード」であり「暗号化」ではない（パスワードや個人情報の格納厳禁）

標準的なJWTはデジタル署名されたJWS（JSON Web Signature）であり、暗号化されたJWE（JSON Web Encryption）ではありません。ペイロードは単にBase64URLで符号化されているだけであり、ネットワーク通信を監視できる人物やブラウザのコンソールを開いたユーザーであれば誰でも平文で閲覧可能です。データベースの認証情報、平文パスワード、マイナンバーなどの個人識別情報（PII）、機密性の高い決済・財務データをJWTクレームに含めてはなりません。

よくある落とし穴とトラブルシューティング

⚠️正しいシークレットを入力しているにもかかわらず無効な署名エラー（SignatureVerificationException）が発生する

このエラーは、認証サーバー（Supabase や Auth0 で一般的）側でシークレットがBase64エンコードされているにもかかわらず、検証ツール側で生のUTF-8プレーンテキストとして入力された場合に発生します。シークレットがBase64形式の場合は、ツール内の「Base64 Secret」トグルが有効になっているか確認してください。また、末尾の改行コード（'\n'）や引用符（クォーテーションマーク）が誤って一緒にペーストされていないかも確認してください。

⚠️トークン生成直後であるにもかかわらず有効期限切れエラー（TokenExpiredError: jwt expired）が発生する

JWTの 'exp' および 'iat' クレームは、Unixエポックからの「秒数（10桁）」で表現される仕様であり、JavaScriptのミリ秒（13桁）ではありません。バックエンドで誤って 'exp: Date.now()' を設定している場合、遠い未来の時刻として解釈されたり、計算ミスによって1970年と判定されたりします。'Math.floor(Date.now() / 1000) + 有効秒数' を使用し、検証側には60秒程度のクロックスキュー許容値（Leeway）を設定してください。

⚠️RS256の署名検証が「無効な鍵フォーマット」または SPKI PEM エラーで失敗する

RS256の検証には、'-----BEGIN PUBLIC KEY-----' で始まり '-----END PUBLIC KEY-----' で終わる SubjectPublicKeyInfo（SPKI）PEM公開鍵が必要です。'-----BEGIN RSA PUBLIC KEY-----' で始まる PKCS#1 形式の鍵や JWKS エンドポイントのJSONを使用している場合は、標準の SPKI 形式に変換するか、x5c 証明書チェーンから有効な PEM エンベロープを抽出してください。

⚠️トークン形式異常エラー：JWTに区切り文字であるピリオドが正確に2つ含まれていない

RFC 7519 準拠の有効なコンパクトJWTは、3つの Base64URL セグメント（Header.Payload.Signature）を区切る正確に2つのピリオド記号で構成されます。HTTPリクエストからトークンをコピーした場合は、先頭の 'Bearer ' プレフィックス、URLクエリエスケープ文字（'%2E'）、末尾の改行コード（'\r\n'）などを除去してから入力・解析してください。

よくある質問 (FAQ)

JWTの署名検証はどのように実行され、どのような数学的・暗号学的要素が必要ですか？▼

JWT署名を検証するには、Base64URLエンコードされたヘッダーとペイロードをピリオドで連結した元の文字列（'header.payload'）を取得し、ヘッダーで指定されたアルゴリズム（'alg'）と検証鍵を用いて暗号ダイジェストを計算した上で、Base64URLデコードされた署名値と比較します。HS256の場合は共有シークレットを用いた HMAC-SHA256 計算が必要であり、RS256の場合は発行者の公開鍵を用いた RSA-SHA256 署名検証演算が必要となります。

JWT認証における HS256 と RS256 の本質的な違いは何ですか？▼

HS256は同一の秘密鍵（シークレット）を用いてトークンの署名と検証の双作業を行う「共通鍵（対称鍵）暗号」であり、認証発行元とAPIゲートウェイが同一のセキュアな内部ネットワークを共有している構成に適しています。一方、RS256は認証サーバーが秘密鍵で署名を発行し、各リソースサーバーが公開鍵（証明書）を用いて検証を行う「公開鍵（非対称鍵）暗号」です。署名用の秘密鍵を公開することなく、マイクロサービス群やサードパーティAPIがトークンの真正性を安全に検証できます。

署名を無効化させずにJWTトークンを改ざん・編集することは可能ですか？▼

不可能です。ユーザー権限を 'user' から 'admin' へ昇格させたり、有効期限タイムスタンプを延長したりするなど、ヘッダーやペイロードのいかなる文字を改ざんしても暗号ハッシュの入力データが変化します。正規の秘密鍵または共有シークレットを所持していない限り、攻撃者が一致する有効な署名を生成することは数学的に不可能であり、RFC準拠の検証システムは無効な署名エラー（Invalid Signature）としてトークンを即座に破棄します。

なぜパスワードやクレジットカード番号などの機密情報をJWTペイロードに保存してはならないのですか？▼

標準的なJWTトークンは電子署名（JWS）されているだけであり、暗号化（JWE）されていないためです。ペイロード部分は単にBase64URLでエンコードされているに過ぎず、機密保護性は一切ありません。通信経路でパケットを傍受した第三者、ブラウザの通信ログを確認できる人物、あるいはローカルストレージにアクセスできるスクリプトであれば、誰でも瞬時にBase64URLをデコードしてすべてのクレーム情報を平文で閲覧できてしまいます。

JWTの登録済みクレーム（Registered Claims）とは何ですか？また iat、exp、nbf は何を意味しますか？▼

登録済みクレームとは、RFC 7519 仕様で事前に定義されている標準メタデータキーのことです。'iat'（Issued At / 発行日時）はトークンが生成されたUnixエポック秒、'exp'（Expiration Time / 有効期限）はトークンが無効と判定される失効エポック秒、'nbf'（Not Before / 有効開始日時）はトークンが有効と認められる最速エポック秒を定義します。そのほか、'iss' はトークン発行元、'sub' はユーザー等の一意の主体（サブジェクト）、'aud' はトークンの利用が想定されている対象受信者（オーディエンス）を表します。

関連開発者ツール

全ツール一覧 →
CSPヘッダー生成ツールセキュリティ

堅牢なContent Security Policy（CSP）ヘッダーを即座に自動生成。script-src、style-src、nonce、ハッシュ値を設定し、XSS攻撃の防止とCSPエラーの解消を支援します。

ツールを開く→
Bcrypt ハッシュ生成＆パスワード検証ツールセキュリティ

ソルトラウンド数 (4〜16) を自由に設定できるEksblowfish暗号ベースのBcryptハッシュ生成＆ローカル検証ツール。完全ブラウザ完結。

ツールを開く→
HMAC 署名生成・整合性検証ツールセキュリティ

RFC 2104 準拠の鍵付きハッシュ（HMAC-SHA256、HMAC-SHA512、HMAC-SHA1、HMAC-MD5）をブラウザ内で瞬時に算出・定数時間（Timing-Safe）検証。

ツールを開く→
クライアントサイド AES-GCM / CBC 暗号化・復号ツールセキュリティ

Web Crypto APIによるブラウザ内ハードウェア高速化AES-256認証暗号。サーバー送信一切なし、完全ローカル実行。

ツールを開く→
RSA 公開鍵・秘密鍵ペア生成ツールセキュリティ

Web Crypto APIを利用して、ブラウザ内で安全に2048/4096ビットのRSA暗号化キーペア（PEM形式）を生成・ダウンロードできます。

ツールを開く→
Base58 / Base58Check 相互変換＆エンコーダーセキュリティ

暗号通貨（ビットコイン、ソラナ）やIPFSで標準採用されるBase58およびBase58Checkのエンコード・デコードツール。誤読防止アルファベットとSHA-256チェックサム検証に対応。

ツールを開く→