ツールナビ
使い方ガイド このサイトについて プライバシーポリシー お問い合わせ
開発ツール 登録不要 無料 ブラウザ完結

JWTデコードツール（無料・ブラウザ完結）

JWT（JSON Web Token）をブラウザ内で安全にデコード。ヘッダー・ペイロード・署名を3分解表示。exp/iat/nbfの有効期限を自動評価、HS256署名検証、標準クレーム日本語解説付き。データはサーバーに送信されません。無料・登録不要。

最終更新：2026年5月14日

ブラウザ完結・サーバー送信なし
貼り付け即デコード・リアルタイム解析
有効期限・標準クレームを自動評価
すべての処理はブラウザ内で完結。JWTや秘密鍵がサーバーに送信されることはありません。

「eyJ」で始まるJWT文字列を貼り付けると自動的にデコードされます

JWT の構造とBase64URLの仕組み

JWTはヘッダー・ペイロード・署名の3パーツをピリオド（.）で連結した文字列です。各パーツはBase64URLエンコードされています。

eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiJ1c2VyMTIzIn0 . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
ヘッダー

アルゴリズム（alg）とトークンタイプ（typ）を格納。Base64URLデコード後はJSONです。

{"alg":"HS256","typ":"JWT"}
ペイロード

ユーザー情報や権限などの「クレーム」を格納。暗号化されていないため秘密情報は入れないこと。

{"sub":"user123","exp":1716681600}
署名

ヘッダー+ペイロードを秘密鍵で署名した値。改ざん検知に使用。秘密鍵がなければ検証できない。

HMACSHA256(base64url(header)+"."+base64url(payload), secret)
Base64URLとは： Base64の変形で、URLに安全な文字のみを使用します。 標準Base64の +→-、/→_に置換し、パディング（=）を省略。 URLパラメータやHTTPヘッダーでそのまま使えます。

標準クレーム（Claims）一覧と意味

RFC 7519で定義された標準クレーム（Registered Claims）の一覧です。これ以外のカスタムクレームも追加可能です。

クレーム名称型説明と用途
iss Issuer（発行者） String JWTを発行したサービス・認証サーバーのURL。受信者がこの値で発行元を確認する。
sub Subject（主体） String JWTの主体（通常はユーザーID）。issの文脈でユニークな値であること。
aud Audience（対象者） String/Array このJWTを受け入れるべきサービス名・URL。受信者は自分がaudに含まれるか確認する。
exp Expiration（有効期限） NumericDate JWTが無効になるUnixタイムスタンプ（秒）。この時刻を過ぎたトークンは拒否される。
nbf Not Before（有効開始） NumericDate JWTが有効になり始めるUnixタイムスタンプ（秒）。この時刻より前のトークンは拒否される。
iat Issued At（発行日時） NumericDate JWTが発行されたUnixタイムスタンプ（秒）。トークンの年齢を判断するために使用。
jti JWT ID（一意識別子） String JWTのユニークID。リプレイ攻撃防止のために使用（サーバー側でブラックリスト管理）。

※ 日時クレーム（exp/nbf/iat）はUnixタイムスタンプ（1970年1月1日UTCからの秒数）で表現します。

アルゴリズム比較：HS256 vs RS256 vs ES256

JWTの署名アルゴリズムは大きく3系統。選択はシステム構成とセキュリティ要件によって異なります。

対称鍵

HS256 / HS384 / HS512

方式：HMAC（Hash-based Message Authentication Code）。同一の秘密鍵で署名・検証。

長所：シンプル・高速・実装が簡単

短所：署名・検証に同じ鍵を使うため、検証側が署名も生成できてしまう（マイクロサービスではリスク）

推奨用途：シングルサーバー・同一チームで完結するシステム

署名鍵: your-256-bit-secret（32文字以上推奨）
非対称鍵（推奨）

RS256 / RS384 / RS512

方式：RSA + SHA。秘密鍵で署名・公開鍵で検証。

長所：公開鍵は公開できる。検証側は署名生成不可。マイクロサービスに最適。

短所：鍵の管理が複雑・HS256より処理が重い

推奨用途：マイクロサービス・外部API・OAuth 2.0 / OpenID Connect

JWKSエンドポイントで公開鍵を配布する構成が一般的
楕円曲線（最新）

ES256 / ES384 / ES512

方式：ECDSA（楕円曲線デジタル署名）。

長所：RSAより小さな鍵サイズで同等のセキュリティ。署名も短い。

短所：実装がより複雑・古いシステムとの互換性に注意

推奨用途：モバイルアプリ・帯域幅が制限される環境・新規設計

ES256はP-256曲線（secp256r1）を使用
「alg: none」は絶対に使わない： 署名なしを意味する none アルゴリズムを受け入れるサーバーは深刻な脆弱性があります（CVE多数）。 本ツールでは none トークンを検出した場合に警告を表示します。

JWT のセキュリティ注意点

JWTのペイロードは暗号化されていますか？
通常のJWT（JWS）のペイロードはBase64URLエンコードされているだけで、暗号化されていません。誰でもデコードして内容を読めます。機密情報（パスワード・クレジットカード番号等）は絶対にペイロードに含めないでください。機密情報を暗号化する必要がある場合はJWE（JSON Web Encryption）を使用します。
このツールで入力したJWTはサーバーに送信されますか？
いいえ。本ツールはすべての処理をブラウザ内のJavaScriptで実行します。入力したJWTや秘密鍵は一切外部サーバーに送信されません。本番環境のトークンも安全に確認できます。
JWT の署名検証はなぜ重要ですか？
JWTのペイロードは誰でも改ざんして偽造できます。署名検証により、ペイロードが発行後に改ざんされていないこと、そして正当な発行者（秘密鍵の所有者）が発行したことを確認できます。署名検証なしにJWTのクレームを信頼することは深刻なセキュリティリスクです。
アクセストークンの有効期限はどのくらいが適切ですか？
アクセストークンは短命（15分〜1時間）に設定し、リフレッシュトークン（7〜30日）でアクセストークンを再発行する構成が推奨されます。有効期限が長いとトークン漏洩時のリスクが高まります。
ブラウザでのデコードは安全ですか？
デコード自体は安全です（ペイロードは暗号化されていないため）。ただし、本番の秘密鍵をブラウザに入力する場合は注意が必要です。開発・デバッグ時のみ使用し、秘密鍵の入力後は必ずクリアすることを推奨します。
JWTとセッションCookieはどちらが安全ですか？
どちらにも一長一短があります。JWTはステートレスでスケールしやすい反面、サーバー側での即時無効化が難しい（ブラックリストが必要）。セッションCookieはサーバー側で即時無効化できる反面、スケールのためにセッションストアが必要です。要件に応じて選択してください。
JWTはどのようにしてサーバーに送りますか？
一般的にJWTはHTTPリクエストのAuthorizationヘッダーにBearer {token}形式で付与します（RFC 6750: Bearer Token Usage）。Cookieに保存してHTTPOnlyフラグを付ける方法もXSS対策として有効です。
RS256に使う公開鍵はどこから取得しますか？
RS256の公開鍵は、IdP（Auth0・Cognito・Keycloak等）が提供するJWKS（JSON Web Key Set）エンドポイントから取得します（RFC 7517: JSON Web Key (JWK)）。通常は/.well-known/jwks.jsonのURLで公開されています。

参考文献・技術仕様の根拠

本ツールが対応する JWT の仕様は、以下の公式標準に基づいています。