JWT デコーダー

例：LINE ログインの ID トークンを読む

LINE Developers の「IDトークンからプロフィール情報を取得する」によると、LINE ログインの ID トークンは JWT で、ウェブログインでは HS256（検証用の鍵はチャネルシークレット）、ネイティブアプリや LINE SDK、LIFF アプリでは ES256 で署名されます。下のトークンは、このページに載っているペイロードの例をそのまま使い、デモ用の文字列 demo-channel-secret で HS256 署名したものです。実際のチャネルとは関係ありません。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FjY2Vzcy5saW5lLm1lIiwic3ViIjoiVTEyMzQ1Njc4OTBhYmNkZWYxMjM0NTY3ODkwYWJjZGVmIiwiYXVkIjoiMTIzNDU2Nzg5MCIsImV4cCI6MTUwNDE2OTA5MiwiaWF0IjoxNTA0MjYzNjU3LCJub25jZSI6IjA5ODc2NTRhc2RmIiwiYW1yIjpbInB3ZCJdLCJuYW1lIjoiVGFybyBMaW5lIiwicGljdHVyZSI6Imh0dHBzOi8vc2FtcGxlX2xpbmUubWUvYUJjZGVmZzEyMzQ1NiJ9.5bqWZz1LSji2XkaXdR0_FS3Q_9E7Ocl9GF-B848uw70

Payload には次の JSON が表示されます（「コピー」でも同じ内容がコピーされ、日付注記は含まれません）。

{
  "iss": "https://access.line.me",
  "sub": "U1234567890abcdef1234567890abcdef",
  "aud": "1234567890",
  "exp": 1504169092,
  "iat": 1504263657,
  "nonce": "0987654asdf",
  "amr": [
    "pwd"
  ],
  "name": "Taro Line",
  "picture": "https://sample_line.me/aBcdefg123456"
}

exp の横には Thu, 31 Aug 2017 08:44:52 GMT — EXPIRED、iat の横には Fri, 01 Sep 2017 11:00:57 GMT と表示されます。日本時間に直すと、有効期限は 2017 年 8 月 31 日 17:44:52、生成時刻は 9 月 1 日 20:00:57 です。ドキュメントの例の値では、有効期限が生成時刻より約 26 時間前になっています。デコーダーは値の前後関係を検査しないので、こうした不自然さは日付を見て自分で気づく必要があります。

同じページには、LINE プラットフォームから直接受け取ったものでない ID トークンは、サーバーで検証するよう書かれています。検証用のエンドポイント（https://api.line.me/oauth2/v2.1/verify）も用意されています。このツールで中身を見られても、トークンが本物かどうかはわかりません。

例：日本語のクレームと日本時間

社内システムのトークンに日本語の氏名や役職が入っている例です。デモ用の秘密鍵 zerotool-demo-secret-ja で署名しました。exp は日本時間 2026 年 10 月 5 日 18:00 です。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTAwNDIiLCJuYW1lIjoi5bGx55Sw5aSq6YOOIiwicm9sZSI6IuW6l-iIl-euoeeQhuiAhSIsImV4cCI6MTc5MTE5MDgwMH0.gq6FePfJmLKXKvgYkH3wmwbW8UegjMT3Hed2yipfQOE

{
  "sub": "user-0042",
  "name": "山田太郎",
  "role": "店舗管理者",
  "exp": 1791190800
}

日本時間の 10 月 5 日 9:00 に開くと、exp の横は Mon, 05 Oct 2026 09:00:00 GMT — valid です。GMT の 09:00 に 9 時間足した 18:00 が日本時間の期限です。18:00 を過ぎてから開くと EXPIRED に変わります。日本語が文字化けしないのは、Base64URL をバイト列に戻してから UTF-8 として読むためです（閉じた環境以外でやり取りする JSON は UTF-8 にすると RFC 8259 §8.1 で決まっています）。

貼り付けでよくある失敗

リクエストヘッダーを行ごとコピーすると、トークンの前に Authorization: Bearer まで入ります。この形のまま「デコード」を押すと、状態欄に Base64URL デコードに失敗しました。 と表示されます。eyJ から始まる部分だけを貼り付けてください。空白を含むので、300 ミリ秒後の自動デコードも動きません。

暗号化された JWE は 5 つの部分からなり、鍵がないと中身を読めません（RFC 7516 §3）。5 つの部分がある入力では 無効な JWT：3 つのパートが必要です。実際: 5. と表示されます。

制限

• トークンの途中の改行と、その前後の空白・タブは無視します。ログやメールで折り返されたトークンもそのままデコードでき、状態欄には デコードしました。 と表示されます。Header や Payload の途中にあるそれ以外の空白・タブはデコード失敗になります。
• 日付を表示するのは、値が数値（秒）の exp・iat・nbf だけです。ネストしたオブジェクトの同名フィールドにも付きます。元の数値はそのまま表示し、日付注記は秒単位までです。ミリ秒の値を入れると、数万年先の日付になります。
• 「valid」「EXPIRED」、署名欄の「not verified」、「(unable to parse)」はどの言語のページでも英語です。
• デコードはできても JSON でない部分は「(unable to parse)」と表示されます。
• 署名は検証しません。サーバー側では、発行元の鍵で署名を検証したうえで exp・nbf・iss・aud を確認してください（RFC 8725 §3）。
• トークンはどこにも保存しません。JWT はログインの資格情報そのものであることが多いため、このページは解析・広告のスクリプトを読み込みません。

JWTについて

JWT はウェブアプリケーションの認証・認可で広く使われています。ユーザーがログインするとサーバーが JWT を発行し、クライアントはその後のリクエストで JWT を Authorization ヘッダーに入れて送ります。デバッグ中にトークンの中身（ユーザー ID、ロール、有効期限など）を確かめたいときにこのツールを使います。テスト用に自分でクレームを決めたトークンを作るには JWT ジェネレーター / 署名ツールが使えます。