JWT デコーダ (ヘッダ・ペイロード・署名・有効期限)

JWT を貼ると即座にヘッダとペイロードを JSON で表示。標準クレーム (iat, exp, nbf) は ISO 8601 に自動変換し、期限切れや未有効を強調表示。

JWT トークン

ブラウザ内で完結。トークンはネットワークを流れません。

ヘッダ

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

ペイロード

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1730000000,
  "exp": 4886000000
}

署名あり: ✓
発行時刻 (iat): 2024-10-27T03:33:20.000Z
有効期限 (exp): 2124-10-30T22:13:20.000Z

仕組み

JWT の構造

JWT は Base64url エンコードされた 3 つのセグメントをドットで連結したもの: header.payload.signature。各セグメントは URL 安全に伝送するため JSON をエンコードしたもの。ヘッダは署名アルゴリズムを宣言、ペイロードはクレーム (subject、expiry、カスタムデータ) を運ぶ。署名があれば受信者が鍵で完全性を検証できる。

本デコーダは最初の 2 セグメントのみ読む。署名は 3 番目だが検証には秘密鍵/公開鍵が必要 — それは別操作。

知っておくべき標準クレーム

iss (issuer): 発行者。iat (issued at): 発行時刻 (Unix タイムスタンプ)。exp (expiry): 有効期限 (Unix)。nbf (not before): 有効になる最早時刻。sub (subject): トークンが代表する主体、通常ユーザ ID。aud (audience): トークンの宛先、通常サービス URL。

全部必須ではない。最小 JWT は sub + iat + exp 程度のことも。カスタムクレームはそれ以外を意味し、ペイロード内で標準と並列する。

デコード ≠ 検証

JWT は誰でもデコード可能 — ヘッダとペイロードは単なる Base64 エンコードされた JSON。だから「ペイロードに秘密を入れない」と言われる: 実質公開情報。

検証は署名を秘密鍵 (HMAC) または公開鍵 (RSA/ECDSA) で照合すること。検証無しではペイロード内のいかなるクレームも信用不可 — 攻撃者は任意のペイロードを偽造可能。

本ツールはデバッグ時の確認用。本番では必ずサーバ側 JWT ライブラリで検証する。

よくある質問

›ここで署名検証できる?

できない — 検証には秘密鍵か公開鍵が必要で、これらは信頼できる環境から外に出すべきでない。サーバ側 JWT ライブラリ (Node の jsonwebtoken、Python の PyJWT 等) を使う。

›トークンは送信される?

送信されません。デコードはローカル動作。受信用サーバ側エンドポイントすら存在しない。

›「無効」と出るのはなぜ?

よくある原因: コピペで空白が混入/欠落、3 セグメント未満、いずれかが不正な Base64url。トリムして再試行。

›Base64url と Base64 の違い?

Base64url は '+' を '-' に、'/' を '_' に、末尾 '=' を省略してエンコードし URL や HTTP ヘッダで安全に運べる。JWT は常に Base64url を使う。

›Unicode ペイロードが文字化けするのはなぜ?

本ツールは標準の UTF-8 でデコード。発行者が他のエンコーディングを使うと JSON.parse が失敗。多くの JWT 発行者は UTF-8 を正しく使う。

›HS256 は安全?

秘密鍵が十分長く (≥256 ビット) 秘匿されていれば安全。HS256 のよくある脆弱性は弱い秘密鍵と alg='none' を許容すること。≥32 文字のランダム鍵を使い 'none' を明示拒否する。

›RS256 と HS256 はどちらがよい?

RS256 (非対称 RSA) は検証用の公開鍵を公開しつつ署名鍵は秘匿できる。HS256 (対称 HMAC) は秘密鍵を全検証者と共有が必要。多サービス構成では RS256 が安全。

›巨大なトークンもデコード可能?

実用上 ~10 MB が限界。それ以上はブラウザが重くなる。JWT は通常 4 KB 未満。それより大きいならクレームに詰めすぎていないか見直し。