JWTデコーダーの使い方｜ヘッダー・ペイロードを貼り付けるだけでJSON表示・exp確認

公開日：2026年7月15日更新日：2026年8月30日運営：シルギア（Analyzegear, Inc.）対象ツール：JWTデコーダー

JWT（JSON Web Token、「ジョット」と読まれることもあります）は、ログイン認証やAPIの認可で広く使われるトークン形式です。サーバーがユーザーIDや有効期限などをまとめて署名し、クライアントはそれを「身分証」のように提示します。Authorization: Bearer … ヘッダーやCookieに入っている、ドットで区切られた長い文字列がJWTであることはよくあります。この記事では、JWTの構造とクレームの読み方、そして「JWTデコーダー」で中身を安全に確認するコツを、実際のデコード結果を交えて説明します。

JWTは「ヘッダー・ペイロード・署名」の3部構成

JWTは3つの部分をドット（.）でつないだ1本の文字列で、xxxxx.yyyyy.zzzzz の形をしています。それぞれの役割は次のとおりです。

ヘッダー（Header）：署名アルゴリズム（alg）やトークン種別（typ）を示すJSON。
ペイロード（Payload）：中身の主張（クレーム）を格納するJSON。誰のトークンか、有効期限などが入ります。
署名（Signature）：ヘッダーとペイロードが改ざんされていないことを保証するための部分。

前半2つは暗号化ではなくBase64URLエンコードされているだけです。Base64URLは、通常のBase64で使う「+」「/」を「-」「_」に置き換え、末尾の「=」パディングを省いた、URLやHTTPヘッダーで安全に使える方式です。符号化であって暗号化ではないので、鍵がなくても誰でも元のJSONに戻せます。

3つの部分を分解して読む

本ツールは、貼り付けたJWTをドットで3分割し、ヘッダーとペイロードをBase64URLデコードして、読みやすいJSONに整形表示します。たとえばヘッダーの eyJhbGciOiJIUzI1NiJ9 をデコードすると { "alg": "HS256" } になります。これは「HMAC-SHA256で署名されている」という意味です。3番目の署名はデコードも検証もせず、そのまま文字列として表示します。

デコードの内部処理は、「-」「_」を標準Base64の「+」「/」に戻し、長さが4の倍数になるようパディングを補い、UTF-8として復元する、という流れです。日本語などのマルチバイト文字を含むクレームも、文字化けせずに読めます。

代表的なクレームの意味

ペイロードには「クレーム」と呼ばれる項目が並びます。RFC 7519で定義された代表的な登録クレームは次のとおりです。

iss（Issuer）：トークンの発行者。認証サーバーのURLなどが入ります。
sub（Subject）：トークンの主体。多くはユーザーIDです。
aud（Audience）：想定される宛先。対象APIの識別子など。
exp（Expiration Time）：有効期限。この時刻を過ぎると失効します。
iat（Issued At）：発行日時。
nbf（Not Before）：この時刻まで無効、という有効開始時刻。

これらに加えて、name・email・scope・roles といったアプリ独自のクレームが入ることもあります。期待どおりの権限やユーザーがトークンに入っているかを、サーバーに問い合わせず手元で確認できるのがデコーダーの利点です。

exp・iat・nbf の時刻を正しく読む

時刻系のクレームは UNIX時刻（1970年1月1日0時からの経過秒数）で書かれているため、数値のままでは読めません。本ツールは端末のローカル日時に変換し、元の数値と併記します。expについては現在時刻と比較し、「あと約○時間」「約○日前に失効」といった残り／超過の目安も添えます。

具体例で見てみましょう。iat: 1735689600 は日本時間（JST）で 2025年1月1日 9:00:00、exp: 1735693200 は 2025年1月1日 10:00:00 にあたります。差は 1735693200−1735689600＝3600秒＝60分なので、これは有効期間1時間のアクセストークンだと読み取れます。もしexpが現在より前なら失効済み、nbfがまだ先の時刻なら「発行はされたが、まだ使えない」状態です。認証で401が返るときは、まずこの3つのクレームを見て切り分けると、原因に早く近づけます。

デコードは復号ではない — 機密を入れない

最も誤解されやすい点です。ヘッダーとペイロードは暗号化されておらず、Base64URLで符号化されているだけです。つまりデコードは復号（暗号解読）ではなく、誰でも中身を読めます。したがって、ペイロードにパスワードやカード番号などの秘密情報を入れてはいけません。逆に、開発中のトークンに機密が紛れ込んでいないかを本ツールで点検する、という使い方もできます。

そしてもう一つ、「中身が読める＝本物・有効」ではありません。本ツールは署名検証を一切行わないため、たとえ改ざんされたトークンでも中身はそのまま表示されます。トークンが正当かどうかは、必ずサーバー側でアルゴリズムと鍵を使った署名検証で判断してください。デコードで確認できるのは、あくまで「何が主張されているか」だけです。

使い方と、うまくいかないときの確認

操作はシンプルです。次の手順で使えます。

header.payload.signature 形式のJWTを入力欄に貼り付けます。貼り付けた瞬間に自動でデコードされます。
ヘッダーとペイロードがJSONで整形表示され、exp・iat・nbfがあれば日時が並びます。各ブロックのコピーボタンで整形済みJSONをコピーできます。
初めての方は「サンプルを入力」ボタンで、実際の表示を試せます。

デコードに失敗する主な原因は、ドットで3つに区切られていない、Base64URLとして不正な文字が混ざっている、デコード結果が正しいJSONでない、のいずれかです。トークンの一部だけをコピーしていないか、前後に空白や改行が混ざっていないかを確認してください。なお処理はすべてお使いのブラウザ内で完結し、JWTが外部に送信されることはありません。ネットワーク通信も発生しませんが、有効な本番トークンはアクセス権そのものでもあるため、取り扱いには十分ご注意ください。

「JWTデコーダー」を使ってみる →