JWT エンコーダー / デコーダー

セグメント	役割	エンコード	例
1	ヘッダー（alg, typ）	Base64URL	eyJhbGciOiJIUzI1NiJ9
2	ペイロード（claims）	Base64URL	eyJzdWIiOiIxMjM0NTY3ODkwIn0
3	署名	Base64URL	SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV…
exp	有効期限	Unix（秒）	1793827200 → 2026-11-04
HS256	HMAC + SHA-256	共有シークレット	最低 32 バイト
RS256	RSA + SHA-256	PEM 公開鍵	非対称検証
Base64 の「+」	—	Base64URL	「-」に置き換え
Base64 の「/」	—	Base64URL	「_」に置き換え

「decoder un JWT」とはどういう意味？

JWT をデコードする （「jwt decode」「decode jwt online」）は、文字列を 2 つのドットで切り分け、各セグメントを Base64URL でデコードして元の JSON を取り出すことです。鍵は不要：ヘッダーとペイロードは暗号化ではなく、エンコードされているだけです。まさに「jwt payload decoder」「decode jwt without verify」の意図 — トークンが何を含むかを見るのであって、本物だと主張するためではありません。

この 2 つの操作は明確に区別してください。 読み取り JWT は何も証明しません：誰でも魅力的なペイロードのトークンを作り、自分のシークレットで署名できます。 検証 すると、内容が第三者に変更されていないことが証明されます。署名の検証をせず「admin: true」と表示するデコーダーは、事実ではなく作り話を語っています。

JWT の 3 つのセグメント

文字列はドットでちょうど 3 つに分かれます： header.payload.signature。ヘッダーには最低限 alg と typ、場合によっては kid どの鍵を使ったかを示します。ペイロードには claims、つまり IANA がレジストリを管理するキーと値のペアが入っています。署名は最初の 2 つのセグメントを、書かれたまま連結した全体をカバーします — 空白 1 つ、文字 1 つでも変わると比較は失敗します。

難しさはすべて、このセグメントが Base64 ではなく Base64URL であることに起因します：プラスはハイフンに、スラッシュはアンダースコアになり、パディング = が消えます。標準 Base64 のデコーダーは有効な JWT でも失敗します。リファレンスタブの「Base64URL と標準 Base64 の比較」表が、まさにこの置き換えを示しています。

署名の検証方法：HS256、RS256、ES256

たとえば HMAC （HS256、HS384、HS512）では、署名にも検証にも同じシークレットが使われます。ツールは次を再計算します： HMAC(secret, base64url(header) + "." + base64url(payload)) その結果を格納された署名と比較します。これは最も多いケースであり、同時に最も危険です：シークレットを持つサービスはどれでもトークンを発行できます。32 バイト未満で環境間で使い回されるシークレットだけで、チェーン全体が破られます。

次に、 非対称アルゴリズム （RS256、RS384、RS512、ES256、ES384、ES512、PS256）では、検証に必要なのは公開鍵だけです。これにより、署名用シークレットを一切共有せずに、第三者が発行したトークンを検証できます。PEM 形式の鍵を貼り付けてください -----BEGIN PUBLIC KEY----- (SPKI)。OpenSSL のエクスポート結果はそのまま使えます。ES256 の署名は生の r||s 形式で、WebCrypto が求めるものです。

そして最後に注意したいのがalg confusion ：あなたのサービスが RS256 を想定しているのに、ヘッダーに HS256 と宣言されたトークンを受け付けてしまう場合、攻撃者は公開鍵（HMAC の鍵になった状態）で署名し、検証を突破します。期待するアルゴリズムはサーバー側で固定し、トークン自身から読み取ってはいけません。

exp、iat、nbf：ハマりやすいタイムスタンプ

この 3 つの Claim は Unix 秒で、ミリ秒もタイムゾーンもありません： iat が 1516239022 なら 2018-01-17T21:30:22Z です。よくある 2 つの間違い：ミリ秒単位の日付と比較する（値が 1 万倍大きくなります）、timestamp を UTC ではなくローカル時刻と解釈すること。「有効期限」タブは双方向に変換し、ISO 8601・ローカル日付・残り時間／経過時間を表示します — 「すでに期限切れ」のトークンが秒単位でわかります。

有効期間を延長してもセキュリティの水準は上がりません。たとえば exp を延長しても変わるのは表示される値で、署名ではありません。再発行する必要があるなら、シークレットか秘密鍵でトークンに再署名してください — それが「エンコード」タブの役割です。

Base64URL：標準のデコーダーが失敗する理由

Base64URL（RFC 4648 §5）が使うアルファベットは A-Z a-z 0-9 - _ で、パディングは認めません。20 文字のペイロードは、 = を除いた後に長さが 4 の倍数にならないことがよくあります。これは正常で、破損ではありません。文字 - と _ は人間の目には曖昧で、報告される「壊れたトークン」の半分がこの原因です。当ツールは両方のアルファベット、大小混在の文字、任意のパディング、そしてプレフィックス Bearer.

セキュリティ：JWT ができないこと

JWT は機密性も失効機能も提供しません。ペイロードは誰でも読めます：メールアドレス、内部ロール、平文で送るわけのない個人情報は決めて入れないでください。また署名済みトークンは exp まで有効で、ログアウトしても残ります — 必要なのは失効リスト、 jti をサーバー側で追跡する方法、または refresh token。おすすめは： exp を短く（10 〜 15 分）、 iat を管理し、 nbf を iat, aud と iss を受け取った時点で検証。

こんな方におすすめ

バックエンド・フロントエンド開発者（OAuth 2.0、OpenID Connect、REST API）、インテグレーターと DevOps（ID 基盤、JWKS、鍵ローテーション）、テスターとペネトレーションテスター（Claim の書き換え、alg confusion、期限切れ）、システム管理者（理由のわからない 401 のデバッグ）、学生（Base64URL と WebCrypto を理解したい）、そして オンライン JWT デコーダー ——速く、網羅的で、機密性も高いものが必要な方へ。あわせて使えるのはBase64 エンコーダー / デコーダー、URL エンコーダー / デコーダー と JSON フォーマッター.

100 % ローカルの JWT デコーダー：トークンが PC の外に出ることはありません

従来のオンライン JWT デコーダーと違い、文字列は一切送信されません：デコード、署名検証、エンコードはすべてブラウザー内で WebCrypto により実行され、外部ライブラリもネットワークリクエストもありません。だからこそ、本物のセッショントークン、ステージングの鍵、社内サービスのトークンを、オフラインや公開ネットワークでも安心して調査できます。履歴と最後の入力はローカル（localStorage）に保存され、デバイスから出ません。

ライセンス Premium Volade は、任意の暗号化クラウド同期を追加します（ツールとは独立）— それ以外は無料・無制限・登録不要のままです。