JWT デコーダー

開発

JSON Web Token（ヘッダー、ペイロード）をデコードし、有効期限と署名を表示します。デコードのみ——署名は検証しません。

100% クライアントサイドバックエンドなし

入力

ヘッダー

ペイロード

発行（iat）
開始（nbf）
有効期限（exp）
署名

このページの内容

JWT とは？#

JWT（JSON Web Token、RFC 7519 で定義）は、2 者間でクレームを運ぶために作られた、コンパクトで URL セーフなトークンです。ログイン後にブラウザが API に送る資格情報、OAuth プロバイダが利用アプリに渡す身元表明、そしてほとんどのモダンなセッション／アクセス制御フローが乗る封筒です。魅力は、クレーム — ユーザーが誰か、何ができるか、トークンがいつ切れるか — がトークン自身の中に JSON として入っているため、受取側のサービスがデータベース検索なしで読めることです。

JWT は必ず 3 つの base64url エンコードされた部分をドットで区切って持ちます。header.payload.signature。ヘッダーはアルゴリズムとトークンタイプを示します。ペイロードはクレームの JSON オブジェクトで、sub（subject）、iat（発行時）、exp（有効期限）、nbf（開始前拒否）などの登録クレームに加え、アプリケーションが追加する任意のカスタムクレームを含みます。署名は発行者が他の 2 つの部分に対し秘密鍵または公開鍵で計算したもので、これを検証することがトークンが改ざんされていないことの証明になります。

本ページは JWT をデコードして検査します。3 つの部分に分割し、ヘッダーとペイロードを base64url デコードして読める JSON にし、標準の時刻クレームを人が読めるタイムスタンプとして表示し、ライブステータスバッジ（有効、期限切れ、まだ開始前）を示します。署名の検証は意図的に行いません — それは発行者の秘密鍵または公開鍵を必要とし、100% クライアントサイドのツールの範囲外です。署名セグメントは、受け取ったまま生で表示されます。

使い方#

左の入力欄にトークンを貼り付けます。ドット区切りの 3 セグメントでなければならず、前後の空白は自動で削られます。
レイアウトがどうなるかを見たいだけならサンプルで組み込みの例トークン（iat／exp／nbf 含む）を読み込みます。
クリアで入力と結果ペインを空にします。
右のパネルを読みます。
- 上部のステータスバッジ — nbf と exp クレームを現在時刻と比較した、緑の 有効、期限切れ、まだ開始前 のいずれか。
- ヘッダーカード（タイトルバーにアルゴリズムが表示、例: HS256）。
- ペイロードカード、JSON としてきれいに整形。
- 時刻クレームリスト — 発行（iat）、開始（nbf）、有効期限（exp）— それぞれ unix タイムスタンプと可読日付の両方として描画。
- 署名セグメント、まだ base64url エンコードされたバイトのまま生で表示。
トークンが不正な場合、赤いステータス行が 3 セグメント形状チェック、base64url デコード、JSON パースのどれに失敗したかを告げます。

主な機能#

ライブの時刻クレームステータス。 iat、nbf、exp を読み、トークンが現在有効か、すでに期限切れか、まだ効力を持たないかを告げます — ログインバグの最中にあなたが実際に尋ねる 3 つの問いです。
人が読める日付。 1700000000 のような Unix エポック数値が、それが表す UTC 日付の隣に示されるため、頭の中でエポック計算をする必要がありません。
アルゴリズムの表面化。 ヘッダーの alg 値がヘッダーカードのタイトルバーに引かれるため、手にしているのが HS256、RS256、それとも予想外の何かかが即座に分かります。
UTF-8 セーフなデコード。 base64url セグメントは TextDecoder を通してバイトとしてデコードされるため、非 ASCII クレーム（別スクリプトの名前、役割）が文字化けではなく正しく描画されます。
デコードのみ — 検証しない。 ツールは決して秘密鍵を求めないため、完全には信頼していないトークンを安全に貼り付けられます — 何もどこにも送信されず、署名は表示されるが検査はされません。

実例#

サンプルをクリックすると、入力にヘッダーが次のようにデコードされるトークンが入ります。

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

ペイロードは次のようにデコードされます。

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

時刻クレームリストは次を示します。

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

現在時刻は nbf の後かつ exp の前であるため、ステータスバッジは有効と読みます。署名セグメントはリテラル文字列 c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ として表示されます — これはテキスト「sample-signature-not-verified」にデコードされ、このトークンの署名が例示であり、本物の HMAC-SHA256 出力ではないことを意図したマーカーです。

この最後の点は、本ツールについて理解すべき最も重要なことです。きれいにデコードされるトークンが、必ずしも信頼に足るトークンとは限りません。誰でもヘッダーとペイロードを偽造できます。発行者の秘密鍵または公開鍵で検証された署名だけが真正性を証明します。本ページはクレームを読み、時間枠をデバッグするために使い、署名検証は実際のバックエンドで行ってください。

よくある質問#

このツールで JWT が本物か分かりますか？#

いいえ。それは意図的なものです。デコードはトークン内の JSON を読むだけであり、トークンが主張する発行者から本当に発行されたことを証明しません。真正性を検証するには、alg に適した鍵（HS256 なら共有秘密鍵、RS256／ES256 なら発行者の公開鍵）と、信頼できるバックエンド上の検証ルーチンが必要です。きれいにデコードされたトークンを検証済みのものとして扱ってはいけません。

ステータスが「期限切れ」と出ます。ここでトークンをリフレッシュできますか？#

いいえ。リフレッシュは、新しいアクセストークンを得るために認証サーバーのリフレッシュエンドポイントを呼ぶことであり — この静的でクライアントサイドのページが実行すべきでない、実行できないネットワーク操作です。ここでできるのは、古いトークンがいつ切れたかを正確に確認することであり、それが通常、必要だった手がかりです。

`iat`、`nbf`、`exp` の違いは何ですか？#

iat（発行時）はトークンが作られた時刻で — 情報的なものです。nbf（開始前拒否）はトークンが受け入れられるべき最早時刻で、nbf の前では署名が有効でも検証サーバーは拒否すべきです。exp（有効期限）はその後トークンが拒否されなければならない硬い打ち切りです。よく形成されたトークンは nbf ≤ iat ≈ now であり、exp は近い将来（アクセストークンなら分単位、リフレッシュトークンならより長く）にあります。

ペイロードに非 ASCII 文字が含まれており、他所では文字化けします。なぜここでは正しいのですか？#

一部のデコーダが各 base64url 文字をバイトと間違って扱うためです。本ページは一旦 Uint8Array にデコードし、それから TextDecoder に通します。これがバイトを正しい UTF-8 として解釈します。それが正しい方法であり、どのスクリプトの名前、役割、スコープも書かれた通りに描画される理由です。