Toolivaro

無料のJWTデコーダー

JWTのヘッダー・ペイロード・クレームをローカルでデコード — オプションでHMAC署名の検証も。ブラウザの外に出るものは何もありません。

JWTデコーダーは、あなたのAPIが発行・消費するJSON Web Token — OAuth 2.0、OpenID Connect、無数の認証ライブラリが使うコンパクトな header.payload.signature 形式 — を読み取り、読みやすい整形済みJSONで表示します:アルゴリズムとキーIDを含むヘッダー、クレームを含むペイロード、そして生の署名セグメントです。デコードはすべてブラウザ内で完結します。base64urlデコードとJSONパースはローカルで行われるため、実在のユーザーIDやメール、セッション情報を運ぶ本番トークンでも安全に使えます — アップロードも記録も保存もありません。このデコーダーがしないのは、過大な主張です。HMAC署名は、シークレットを貼り付ければ検証できます:ツールはWebCryptoでHMACを計算し、「署名は有効」「署名は無効」と報告します。これにより、トークンがあなたの保持するシークレットで実際に署名され、転送中に改ざんされていないことを確認できます。この検証はその範囲について正直です:ブラウザで共有シークレットにより検証できるのはHS256、HS384、HS512のみ。非対称トークン — RS256、ES256、PS256とその仲間 — は本番の標準であり、検証には署名者の公開鍵が必要ですが、クライアント側ツールがそれをあなたの代わりに取得することはできません。デコーダーは推測する代わりに、そのことを正確に伝えます。悪名高く危険なalg=noneのトークンは、「署名なし・保護なし」としてフラグ付けされます。有効期限や発行時刻のクレーム(exp、iat、nbf)は、トークンが運ぶままの生のepoch値でペイロードJSON内に表示されます — ツールは変換も解釈もしません。静かな変換こそ、デコーダーが嘘をつく場所だからです。ログやネットワークインスペクター、テストからトークンを貼り付けて、サーバーと同じように読みましょう。

ブラウザ内でローカル処理されます

完全なトークン — header.payload.signature を貼り付けます。

HS256/384/512署名をローカルで検証します — シークレットがブラウザの外に出ることはありません。

結果はどうやって計算されるの?

ログからIDトークンを読む

サービスのアクセスログに、RFC 7515の例のようなトークンがあります — HS256を宣言するヘッダー、subject・名前・発行時刻を含むペイロード、そして署名セグメント。サーバーと同じようにクレームを読むためにデコードし、次に共有シークレットを貼り付けて署名が本当に一致するか確認します — 改ざんされたsubや期限切れのiatは「署名は無効」として表示されます。

入力と出力の例
入力
トークン eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
HMACシークレット(任意) your-256-bit-secret
結果 {"sub":"1234567890","name":"John Doe","iat":1516239022} — 署名は有効

計算式と前提は?

JWTコンパクトシリアライゼーション

JWT = base64url(ヘッダー) + "." + base64url(ペイロード) + "." + base64url(署名)

計算式の記号
記号 意味
ヘッダー JSONヘッダー:alg、typ、多くの場合はkid — 署名アルゴリズムとキーID
ペイロード JSONクレーム:登録済み(sub、iat、exp、nbf、iss、aud)に加えカスタムクレーム
base64url URL安全文字(-と_)を使いパディングなしのbase64

RFC 7519 §3.1。ツールはセグメントをbase64urlでデコードしてJSONを整形します。クレームを並べ替えたり解釈したりすることはありません。

HMAC署名検証

有効 = verify(HMAC-{SHA-256|384|512}(シークレット), base64url(header.payload), 署名)

計算式の記号
記号 意味
シークレット 貼り付ける共有HMACシークレット — ブラウザ内でのみ使用され、送信はされません
base64url(header.payload) 署名入力:トークンが運ぶままの最初の2セグメント
署名 3番目のセグメントで、生のMACバイトにデコードされたもの

crypto.subtle.verifyは定数時間の比較を行うため、不一致がタイミングで漏れることはありません。非対称アルゴリズムは署名者の公開鍵が必要で、ローカルでは検証不可と報告されます。

よくある間違いは?

  • デコードできるからトークンを信頼する — デコードはクレームを見せるだけで、誰が署名したかは示しません。発信元を証明できるのは有効な署名検証だけで、しかも正しいシークレットを使ったHMACトークンに限られます。
  • alg=noneのトークンは「デコードしても無害」と思い込む — これらは署名なしであり、受け入れるライブラリはすべて拒否すべきです。
  • 本番トークンをアップロードするオンラインデコーダーに貼り付ける — このツールは完全にローカルです。多くのWebサービスはあなたのトークンとクレームを保存します。

前提と制限は?

  • 署名検証はHMAC(HS256/384/512)のみ対応 — 非対称トークンは「ローカルでは検証不可」と報告されます。
  • クレームは生のまま表示されます(exp/iat/nbfはepoch秒)。変換は行いません。
  • 不透明なアクセストークンはJWTではないためデコードできません。

数値の出典は?

最終確認 2026年8月12日 · バージョン 1.0.0 · Toolivaro 外部コンテンツを保証するものではありません。

よくある質問

トークンはどこかにアップロードされますか?

いいえ。デコードと署名検証はWebCryptoを使って完全にブラウザ内で実行されます — トークンやシークレットを使ったネットワークリクエストは一切行われません。実在のユーザークレームを持つ本番トークンにも安全です。

なぜRS256トークンを検証できないのですか?

RS256や他の非対称ファミリーは署名者の公開鍵で検証しますが、その鍵は発行者のJWKSエンドポイントにあります — クライアント側ツールがあなたの代わりにその鍵を安全に取得し信頼することはできません。デコーダーは結果を偽装する代わりに、そのようなトークンを「ローカルでは検証不可」と報告します。HMAC(HS256/384/512)トークンは共有シークレットだけで済むため、シークレットを提供すれば検証されます。

トークンがalg=noneの場合はどういう意味ですか?

alg=noneは、トークンがまったく署名されていないことを宣言しています。noneを受け入れるライブラリは、悪名高い認証バイパスの原因です。デコーダーはそのようなトークンを「保護なし」としてフラグ付けし、検証すべき署名セグメントもありません。

なぜexpやiatが生の数値で表示されるのですか?

トークンがそのように運ぶからです — RFC 7519によるNumericDateのepoch秒。ツールはクレームを黙って変換も解釈もしません。静かな変換こそデコーダーが嘘をつく場所であり、生の値こそサーバーが見る真実です。

OAuth 2.0のアクセストークンもデコードできますか?

JWTである場合に限ります。多くのプロバイダー(Okta、Auth0、Azure AD)はJWTアクセストークンを発行しており、それらはここでデコードできます。不透明トークン — 単なる識別子であるランダム文字列 — は中にJSONがなくJWTではありません。どんなデコーダーもそれをクレームにはできません。

このコレクションの一部 パスワード・ハッシュ・セキュリティツール

間違いを見つけましたか? 報告する — すべての修正を確認します.

このツールは役に立ちましたか?

Toolivaro編集チームが当社の方法論に基づいてレビュー済み 計算方法 · 編集方針