JWT デコーダ

JWT デコーダーとは？

JWT デコーダーは、JSON Web Token をヘッダー・ペイロード・署名の 3 つに分解し、最初の 2 つを Base64URL デコードして JSON として読めるようにするツールです。ログインフロー、認可、セッションのクレーム、トークンの有効期限まわりをデバッグするとき、開発者は本当によくお世話になります。

JWT のデコードは、そのトークンを「信用する」ことと同じではありません。ヘッダーとペイロードはあくまで Base64URL エンコードされているだけで、暗号化されていません。誰でも読めるのが仕様です。発行元が署名したものか、改ざんされていないかを確認するのは「検証（verify）」のステップです。

JWT は header.payload.signature という形をしています。それぞれの部分が Base64URL でエンコードされ、ドット（.）で繋がれています。ヘッダーには使用している署名アルゴリズム、ペイロードにはクレーム（ユーザーは誰か、いつ期限切れか、何ができるか）、署名にはトークンが改ざんされていないことをサーバーが確認するための情報が入っています。

JWT をデコードしながら身につくこと

• JWT は Base64URL エンコードされた 3 つのパートをドットで繋いだ構造： header.payload.signature。
• sub・role・iat・nbf・exp といった代表的なクレームは、ユーザー識別、権限、発行時刻、有効期限を表す。
• デコードしたペイロードは誰でも書き換えられる — 改ざんを検知できるのは署名だけ。

JWT をデコードする手順

1. 1

   トークン全体を貼り付ける

   入力欄に JWT をそのまま貼り付けます。xxxx.yyyy.zzzz のように、Base64URL エンコードされた 3 つのパートがドットで繋がった形になっているはずです。

2. 2

   ヘッダーを読む

   ヘッダーには署名アルゴリズム（alg）とトークン種別が書かれています。要注意なのは "alg": "none" — これは無署名トークンで、信用してはいけません。

3. 3

   ペイロードのクレームを読む

   ペイロードはクレームが詰まった JSON です。sub（ユーザー ID）、exp（有効期限）、iat（発行時刻）に加えて、アプリ独自の role や tenant などのカスタムクレームも確認しましょう。

4. 4

   有効期限をチェック

   exp の Unix タイムスタンプを日時に変換します。すでに過去の時刻なら、そのトークンは期限切れ。きちんと作られた API なら拒否されるはずです。

5. 5

   署名を検証する（任意）

   シークレットや公開鍵が手元にあれば、ベリファイアに貼り付けて署名が正しいか確認できます。署名が通って初めて、ペイロードの中身を信頼できる状態になります。

JWT 標準クレーム一覧

ここに載せたのは、JWT 仕様（RFC 7519）で定義されている登録済みクレームです。アプリは独自のカスタムクレームを自由に追加できます。

試してみたい JWT のサンプル

{  "alg": "HS256",  "typ": "JWT"}

{  "sub": "user_123",  "role": "student",  "exp": 1710000000}

{  "exp": 1710000000}

{  "alg": "none",  "typ": "JWT"}

JWT でよくある落とし穴

• パスワード、シークレット、機微な個人情報をペイロードに入れてしまう。JWT は読めるだけで、暗号化はされていません。
• 署名を確認せずに、デコードしただけで「有効なトークン」と判断してしまう。
• Base64URL で読めることと「暗号化されている」ことを混同する — JWT のペイロードは読めるのが仕様。

JWT のよくある質問