開発者向け
JWTデコーダー・ジェネレーター
JWTのデコード(Header・Payload・署名表示・有効期限判定)に加え、HS256/HS384/HS512 でのJWT生成にも対応。すべてブラウザ内処理。
登録不要
JWTデコーダー・ジェネレーターについて
JWT(JSON Web Token)とは
JWT(JSON Web Token)は、RFC 7519で定義されたトークン形式で、主にWeb認証・認可で使われます。コンパクトでURLセーフな形式で、JSON形式のクレーム(情報)を安全に転送できます。
JWTはOAuth 2.0、OpenID Connect、APIの認証トークンなどで広く利用されています。Firebase Auth、Auth0、AWS Cognitoなどの認証サービスもJWTを発行します。
JWTの構造(Header・Payload・Signature)
JWTはドット(.)で区切られた3つのBase64urlエンコード済みパートで構成されます。
- Header(ヘッダー):署名アルゴリズム(alg)やトークン種別(typ)を含むJSONオブジェクト。例:
{"alg":"HS256","typ":"JWT"} - Payload(ペイロード):クレーム(claims)と呼ばれるデータを含むJSONオブジェクト。ユーザーIDや有効期限などの情報が格納されます。
- Signature(署名):ヘッダーとペイロードを秘密鍵で署名したもの。改ざん検知に使われます。
形式: xxxxx.yyyyy.zzzzz(ヘッダー.ペイロード.署名)
このデコーダーの仕組み
本ツールはJWTトークンをクライアントサイド(ブラウザ内)でデコードします。サーバーへのデータ送信は一切行いません。
- トークンをドットで3つのパートに分割
- 各パートをBase64urlデコードしてJSONに変換
- タイムスタンプクレーム(exp, iat, nbf)を人間が読める日時に変換
- 有効期限の判定(期限切れ / 有効)
注意: 署名の検証は行いません。署名検証には秘密鍵または公開鍵が必要であり、ブラウザ上での安全な検証には適さないためです。
よく使われるクレーム(Claims)
JWTペイロードには「クレーム」と呼ばれるキーバリューペアが含まれます。RFC 7519で定義された登録済みクレームは以下の通りです。
- iss(Issuer):トークンの発行者
- sub(Subject):トークンの主体(通常はユーザーID)
- aud(Audience):トークンの受信者
- exp(Expiration Time):有効期限(Unixタイムスタンプ)
- nbf(Not Before):この時刻より前は無効
- iat(Issued At):発行時刻
- jti(JWT ID):トークンの一意識別子
これら以外にも、アプリケーション固有のカスタムクレーム(name, email, roleなど)を自由に追加できます。
セキュリティに関する注意事項
JWTデコーダーを使用する際は、以下の点にご注意ください。
- 本番環境のトークンは慎重に:JWTのペイロードは暗号化されていないため、デコードすると個人情報やセッション情報が閲覧できます。機密性の高い本番トークンの取り扱いには注意してください。
- 署名は検証されません:本ツールはデコードのみを行い、署名の正当性は検証しません。トークンの信頼性を確認するには、サーバー側で署名を検証する必要があります。
- クライアント側で完結:本ツールはすべての処理をブラウザ内で行います。入力されたトークンがサーバーに送信されることはありません。
- JWTは暗号化ではない:JWTはBase64urlでエンコードされているだけで、暗号化されていません。誰でもデコード可能です。機密情報はペイロードに含めないでください。
よくある質問
- Q. 入力したJWTトークンはサーバーに送信されますか?
- いいえ。すべての処理はブラウザ内のJavaScriptで完結しており、入力されたトークンがサーバーに送信されることはありません。安心してご利用ください。
- Q. JWTの署名は検証できますか?
- 本ツールでは署名の検証は行いません。署名の検証には秘密鍵(HMAC系)または公開鍵(RSA/ECDSA系)が必要です。署名検証はサーバーサイドで行ってください。
- Q. 期限切れのJWTでもデコードできますか?
- はい。JWTの有効期限はペイロード内のexpクレームで管理されており、デコード自体は期限に関係なく行えます。本ツールでは有効期限のステータスも合わせて表示します。
- Q. JWTとJWSとJWEの違いは何ですか?
- JWTはトークンの形式で、JWS(JSON Web Signature)は署名付きのJWT、JWE(JSON Web Encryption)は暗号化されたJWTです。一般的に「JWT」と呼ばれるものの多くはJWSです。本ツールはJWS形式のJWTをデコードします。
- Q. Base64とBase64urlの違いは何ですか?
- Base64urlはURL/ファイル名で安全に使えるよう、標準Base64の「+」を「-」に、「/」を「_」に置換し、パディング「=」を省略した変種です。JWTはBase64urlエンコーディングを使用します。
- Q. JWTのペイロードに機密情報を入れてもよいですか?
- 推奨しません。JWTのペイロードはBase64urlでエンコードされているだけで暗号化されていないため、誰でも簡単にデコードして内容を読めます。パスワードやクレジットカード番号などの機密情報は絶対にペイロードに含めないでください。
関連記事
パスキーはなぜフィッシングに強いのか ― WebAuthn / FIDO2 と公開鍵ログインの仕組み
パスキー(passkey)は、パスワードを保存しないログイン方式です。WebAuthn / FIDO2 の公開鍵認証、チャレンジ署名、origin / RP ID への結びつき、同期パスキーと端末固定キーの違い、復旧設計の注意点を整理します。
Cookie はなぜ壊れやすいのか ― SameSite / Secure / HttpOnly / Partitioned を正しく読む
Cookie の Secure、HttpOnly、SameSite、Partitioned(CHIPS)、__Host- / __Secure- プレフィックスは、それぞれ守る対象が違います。CSRF、XSS、第三者Cookie廃止、埋め込みウィジェットの状態管理まで、Set-Cookie 属性の設計意図を整理します。
SNI はなぜ見えていたのか ― TLS Encrypted ClientHello(ECH)と HTTPS の最後の平文
HTTPSでも、TLSハンドシェイクのSNIは長く平文で送られてきました。2026年にRFC 9849として標準化された TLS Encrypted ClientHello(ECH) が何を隠し、何を隠さないのかを、TLS 1.3、ClientHelloInner/Outer、HTTPS/SVCB DNSレコード、DoHとの関係から整理します。
量子コンピュータで TLS は破られるのか ― ML-KEM / Kyber とポスト量子暗号の実務
NIST は 2024 年に ML-KEM、ML-DSA、SLH-DSA を正式標準化しました。量子コンピュータが RSA / ECC に与える影響、Harvest Now, Decrypt Later、Kyber から ML-KEM への改名、TLS のハイブリッド鍵交換、開発者が今やるべきことを整理します。
このツールを評価
—(0件)


