JWTデコーダー
端末内で動作し、何も送信されません。すべてお使いのデバイス上で処理されます。トークンがどこかに送信されることはありません。
JSON Web Tokenをブラウザ内だけでデコード・検査できます - ヘッダー、ペイロード、有効期限、任意の署名検証を含み、どこにもアップロードされません。
JSON Web Token（JWT）は、2者間でクレームを表現するためのコンパクでURLセーフな方式で、"Authorization: Bearer ..."ヘッダーからセッションCookie、シングルサインオン（SSO）まであらゆる場所で使われています。JWTはドットで結合された3つのbase64urlエンコード部分（ヘッダー、ペイロード、署名）に過ぎないため、署名鍵を必要とせずに誰でもヘッダーとペイロードをデコードして読むことができます - 署名を検証する場合のみシークレットまたは秘密鍵が必要です。このツールは両方の部分をブラウザ内でローカルにデコードし、標準クレームを説明し、期限切れまたはまだ有効でないトークンにフラグを立て、"none"アルゴリズムというセキュリティ上の落とし穴について警告します - トークンがどこかに送信されることはありません。
よくある質問
私のJWTはサーバーに送信されますか？
いいえ。デコードはブラウザ内で、WebのatobとTextDecoder APIのみを使って完全に行われます - トークンや、署名検証のために貼り付けたシークレット・公開鍵がデバイスから外に出ることはありません。
このツールで署名を検証できますか？
はい、ベストエフォートのおまけ機能として可能です。HMACシークレット（HS256/384/512用）を知っているか、PEM形式の公開鍵（RS256/384/512またはES256/384/512用）を貼り付ければ、ブラウザのWeb Crypto APIを使ってローカルで署名を確認します。鍵がない場合はヘッダーとペイロードのデコードと表示のみが行われます - デコード自体は署名鍵を必要としません。
なぜアルゴリズムが"none"と表示されるのですか？
"alg": "none"は、トークンがまったく署名されていないことを意味します - 誰でも任意のクレームを書き込むことができた可能性があります。一部のライブラリは過去にこうした署名なしトークンを誤って有効と受け入れており、これはよく知られた認証回避手法となりました。このツールは見逃さないよう常に目立つ形で警告します。
exp、iat、nbfとは何ですか？
これらはRFC 7519で定義された標準的なタイムスタンプクレームです。iatはトークンが発行された時刻、nbfはトークンが有効になる最も早い時刻、expはトークンが無効になる時刻を示します。3つともNumericDate（Unixエポックからの秒数）として保存されており、このツールはこれを読みやすい日付と「あと2時間で期限切れ」のような相対時間に変換します。
なぜシークレットなしでペイロードを読めるのですか？
JWTのヘッダーとペイロードはbase64urlでエンコードされているだけで、暗号化されていないためです - エンコードは秘匿性ではありません。トークンを持っている人は誰でもすでにクレームを読むことができます。署名は、鍵を持たない人によってクレームが改ざんされていないことを証明するだけです。攻撃者に直接読まれたくない情報は、決してJWTのペイロードに入れないでください。
トークンには3つの部分がありますが、それでもデコードできません。なぜですか？
3つのセグメント（ヘッダー、ペイロード、署名）はそれぞれ有効なbase64urlテキストである必要があり、ヘッダーとペイロードは有効なJSONにデコードできる必要があります。このツールはヘッダーとペイロードを個別にデコードし、静かに失敗する代わりに、どちらが壊れているのか、なぜなのか（不正なbase64、不正なUTF-8、または無効なJSON）を正確に教えてくれます。
開発者向け：URLに `token` パラメータを付けてこのページを開くと（例：gizke.com/jwt?token=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c）、そのトークンが自動的に入力された状態で表示されます。ほとんどの訪問者には不要な機能で、すぐに使える例に直接リンクするためのものです。