JWT デコーダー

JWT（JSON Web Token）をデコードして、ヘッダー・ペイロード・有効期限を確認できます。

完全無料ブラウザ完結登録不要安全

JWT を入力（xxxxx.yyyyy.zzzzz 形式）

このツールについて

入力したJWTはブラウザ内のみで処理されます。サーバーへ送信されません。
本ツールは「デコード」のみで、署名の検証は行いません（検証には秘密鍵が必要です）。
JWT は暗号化ではないため、本番のトークンには機密情報を含めないでください。

使い方

1テキストエリアに JWT 文字列を貼り付けます（xxxxx.yyyyy.zzzzz の形式）。
2ヘッダー・ペイロードが自動でデコードされ、JSON 整形済みで表示されます。
3ペイロード内の exp（有効期限）が読み取られ、現在時刻と比較して状態（VALID/EXPIRED）が表示されます。
4各ブロックのコピーボタンで JSON をクリップボードへ。

よくある利用シーン

API認証で受け取ったトークンの中身を確認
有効期限（exp）が切れていないか即座に判定
ペイロードに想定どおりのクレームが入っているかデバッグ
他社サービスの SSO 連携で JWT 構造を確認
JWT のテスト・モック作成時の検証

よくある質問

JWT デコーダーは無料で使えますか？

はい、完全無料です。登録やサインインも不要です。

入力した JWT はサーバーへ送信されますか？

いいえ。すべての処理はブラウザ内で完結します。トークンがサーバーへ送信されることはありません。

JWT の署名が正しいかも検証できますか？

いいえ、本ツールはデコード（中身の解読）のみです。署名検証には発行者の秘密鍵（HS256など）や公開鍵（RS256など）が必要で、それらをブラウザに入力するのはセキュリティ上推奨しません。

JWT は暗号化されていますか？

いいえ、標準のJWT（JWS形式）は単にBase64URLでエンコードされているだけで、中身は誰でも読めます。機密情報を入れるとブラウザの開発者ツールから簡単に見えてしまうので注意してください。

「不正な JWT」と出ます。何が悪いですか？

JWT は必ず3つの部分をピリオド (.) で区切る形式です（header.payload.signature）。ピリオドの数が違う・空白や改行が混ざっている・URLセーフではないBase64 になっているなどが原因です。

本ツールを使いこなすポイント

Base64URL の仕組みは Base64エンコード徹底解説、JSONの構文は JSON 完全入門でまとめています。ここでは、本ツールでJWTを扱うときの実用ポイントに絞って整理します。

JWT の3部構成 — header.payload.signature

JWT（JSON Web Token）は次の3つの部分を . でつないだ文字列です。

Header：アルゴリズム（alg）とタイプ（typ）。例：{ "alg": "HS256", "typ": "JWT" }
Payload：実際の中身（クレーム）。sub（subject）・exp（有効期限）・任意のカスタムフィールド。
Signature：「ヘッダー＋ペイロード」を秘密鍵で署名した値。これにより改ざんを検出できる。

本ツールはヘッダーとペイロードを Base64URL デコードして JSON 整形表示します。署名はデコードできない（公開鍵 or 秘密鍵が必要）ため、そのまま表示するだけです。

標準クレームの読み方 — exp / iat / nbf / iss / sub

RFC 7519 で定義された標準クレームのうち、本ツールが特別に整形表示するものを紹介します。

exp (Expiration)：有効期限。Unixタイムスタンプ（秒）。本ツールは人間可読な日時に変換し、現在時刻と比較して VALID / EXPIRED ラベルを表示します。
iat (Issued At)：発行時刻。
nbf (Not Before)：この時刻より前は有効でない（将来発効するトークン）。
iss (Issuer)：発行者（例：認可サーバのURL）。
sub (Subject)：主体（多くはユーザーID）。
aud (Audience)：受信者（このトークンを利用すべきサービス）。

JWT は「暗号化」ではない — 機密情報を入れない

よくある誤解：「JWT は暗号化されているから秘密情報を入れても大丈夫」——これは大きな間違いです。

標準の JWT（JWS 形式）はペイロードを単に Base64URL エンコードしているだけで、誰でも本ツールのようなデコーダーで中身を読めます。署名は「改ざん検出」のためで、「中身の秘匿」のためではありません。

× パスワード・クレジットカード番号・APIキーをペイロードに入れる
× 個人情報（住所・電話番号）をペイロードに入れる
○ ユーザーID・ロール（admin/user）・有効期限など、漏れても問題ない値だけ入れる

本当に中身を秘匿したい場合は JWE（JSON Web Encryption）形式を使う必要があります（実装は複雑で、現代ではほぼ使われません）。

署名検証は別途必要 — 本ツールは「読む」だけ

本ツールはJWTの中身を解読するだけで、署名が正しいかどうかは検証しません。

実運用では、JWT を受け取ったサーバ側で必ず署名検証を行います。

HS256（対称鍵）：発行サーバと検証サーバが同じ秘密鍵を共有する方式。
RS256 / ES256（公開鍵）：発行サーバが秘密鍵で署名、検証サーバは公開鍵で検証する方式。外部サービスとの連携で主流。

開発時の手元検証用にはこのデコーダで十分ですが、本番のアクセス制御ではサーバ側ライブラリ（jsonwebtoken、jose など）で署名検証を必ず行ってください。

alg: none の落とし穴 — 古いJWTライブラリの脆弱性

歴史的に有名な脆弱性として「alg: none 攻撃」があります。一部の古いライブラリは { "alg": "none" } のヘッダを持つトークンを「署名検証不要」として通してしまい、攻撃者がペイロードを書き換えても受け入れられてしまうという問題でした。

本ツールでデコード結果のヘッダに alg: none が出ているJWTを見たら警戒してください。発行元の実装に問題がある可能性があります。