JWT デコーダー・エンコーダー — JSON Web Token のデコード、検証、署名
JWT のヘッダーとペイロードをデコードし、有効期限をわかりやすく表示し、HS・RS・PS・ES の署名を検証したり、新しいトークンに署名したりできます。何もブラウザの外に出ません。
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user_42",
"name": "Ada Lovelace",
"role": "admin",
"iat": 1757320000,
"exp": 1788856000
}| sub | サブジェクト | user_42 |
| name | Ada Lovelace | |
| role | admin | |
| iat | 発行日時 | 1757320000 |
| exp | 有効期限 | 1788856000 |
例のトークンはシークレット demo-secret-do-not-use で署名されています。
デコードでは署名は確認されません。JWT は誰でも読めるので、誰が発行したかを証明できるのは署名だけです。HS* のトークンには共有シークレットが、RS*、PS*、ES*、EdDSA には発行者の公開鍵（PEM、証明書、JWK、または /.well-known/jwks.json の JWKS。kid で照合）が必要です。本番環境のシークレットや秘密鍵は、このページを含めどの Web ページにも貼り付けないでください。テスト用の鍵を使いましょう。
トークンと鍵は WebCrypto を使ってブラウザ内で処理され、どこにも送信されません。それでも、貼り付けた本番環境のトークンや鍵は認証情報として扱ってください。 すべての無料ツールを見る.
不具合や改善できそうな点を見つけましたか？いただいたメッセージはすべて読み、すぐに対応します。
この無料の JWT デコーダーは、JSON Web Token のヘッダー、ペイロード、クレームを表示し、exp、iat、nbf を読みやすい日時にして有効か期限切れかをはっきり判定し、署名を検証します（シークレットによる HMAC、または公開鍵、証明書、JWK による RSA、RSA-PSS、ECDSA、Ed25519）。テスト用に新しいトークンに署名するエンコーダーもあります。すべてブラウザ内で行われます。これはたいていのツール以上に重要な点です。貼り付けたトークンは有効な認証情報であることが多く、当サイトを含め、誰のサーバーにも送信されるべきではないからです。
JWT は、ドットで区切られた 3 つの Base64URL のセクションです。アルゴリズムを示すヘッダー、クレームを含むペイロード、そして署名です。最初の 2 つは暗号化されておらず、エンコードされているだけなので、誰でも読めます。トークンの発行者と、改ざんされていないことを証明するのは署名です。したがって、デコードできることと信頼できることは同じではなく、このページはその区別が常にわかるようにしています。
使い方
- トークンを貼り付けます。Authorization ヘッダーの先頭の「Bearer 」が付いていても問題なく、取り除かれます。
- ステータス行を確認します。あとどれくらい有効か、いつから期限切れか、またはまだ有効になっていないかが表示されます。
- ペイロードとクレームの表を確認します。時刻のクレームは、元の Unix 秒と並べてローカルの日時で表示されます。
- 検証するには、鍵を入力して「検証」を押します。HS256/384/512 なら共有シークレット、RS、PS、ES、EdDSA のトークンなら発行者の公開鍵を、PEM、証明書、JWK、または JWKS 全体として入力します（鍵はトークンの kid で選ばれます）。
- トークンを作成するには「エンコード・署名」に切り替え、アルゴリズムを選び、ヘッダーとペイロードの JSON を編集して、シークレットを入力するか PKCS#8 の秘密鍵を貼り付けます（テスト用の鍵ペアを生成することもできます）。署名したら、デコーダーで開いて検証します。
- バグ報告やテスト用データに必要なら、ペイロードやヘッダーを整形した JSON としてコピーします。
よくある質問
本物のトークンをここに貼り付けても安全ですか？
トークンはブラウザ内の JavaScript でデコードされ、送信されることはありません。インターネットから切断してもページは動き続けます。とはいえ、本番のトークンはパスワードと同じように扱ってください。信頼できないページには貼り付けず、できるだけ有効期間の短いテスト用トークンを使いましょう。
シークレットなしでペイロードを読めるのはなぜですか？
JWT は署名されているだけで、暗号化されていないからです。ペイロードは Base64URL でエンコードされた JSON で、誰でもデコードできます。シークレット（または秘密鍵）が必要なのは、署名の作成と検証のときだけです。暗号化版の JWE を使う場合を除き、JWT のペイロードに機密データを入れないでください。このツールは JWE をデコードしません。
exp、iat、nbf の意味は？
どれも秒単位の Unix タイムスタンプです。exp はトークンの有効期限、iat は発行日時、nbf（not before）は有効になる最も早い時点です。検証する側は、exp を過ぎたトークンや nbf より前のトークンを拒否しなければなりません。ここのステータス行は、両方のルールを現在時刻に適用しています。
RS256 や ES256 のトークンを検証するには？
必要なのは発行者の公開鍵で、秘密鍵は決して使いません。ID プロバイダーは、https://issuer/.well-known/jwks.json のような URL で JWKS として公開鍵を公開しています（Auth0、Okta、Cognito、Azure AD、Google はいずれもそうしています）。JWKS 全体を貼り付ければ、トークンのヘッダーと kid が一致する鍵が使われます。単一の JWK、PEM 公開鍵（BEGIN PUBLIC KEY）、X.509 証明書を貼り付けることもできます。このページ自体は何も取得しないので、JWKS はブラウザからコピーしてください。
ここで JWT を作成して署名できますか？
はい。「エンコード・署名」は、ヘッダーとペイロードの JSON を受け取り、HS256/384/512 とシークレット、または RS、PS、ES、EdDSA と PKCS#8 PEM 形式（BEGIN PRIVATE KEY）の秘密鍵で署名します。古い BEGIN RSA PRIVATE KEY のファイルは PKCS#1 なので、openssl pkcs8 -topk8 -nocrypt -in key.pem で変換してください。使うのはテスト用の鍵だけにしましょう。本番の署名鍵をどこかの Web ページに貼り付けたら、漏えいしたものとみなすべきです。
「alg: none」とは何ですか？ なぜ警告が出るのですか？
トークンに署名がないことを宣言しています。かつて一部のライブラリはこのようなトークンを有効として受け付けてしまい、攻撃者が任意のペイロードを偽造できました。正しく設定された検証処理は、alg none を即座に拒否します。実際のシステムでこれを見つけたら、珍しいものではなく、セキュリティ上の問題です。
JWT の構造
ヘッダー：{"alg":"HS256","typ":"JWT"} は、どのアルゴリズムでトークンに署名したかを検証側に伝えます。ペイロード：クレームです。発行者が含めることにした任意の内容と、検証側が理解する登録済みクレーム（iss、sub、aud、exp、nbf、iat、jti）からなる JSON オブジェクトです。署名：base64url(header).base64url(payload) に対する HMAC またはデジタル署名です。ペイロードを 1 文字でも変えれば署名は一致しなくなります。それこそが署名の目的です。
JWT のよくある間違い
• 署名を検証せずにペイロードを信頼する、またはサーバーが想定するアルゴリズムではなくトークンに書かれたアルゴリズムで検証する（アルゴリズムの混同）。
• 有効期間の長いアクセストークン。exp は短く（数分〜1 時間）し、長いセッションにはリフレッシュトークンを使いましょう。
• ペイロードに個人情報や機密データを入れる。トークンを持っている人なら誰でも読めます。
• XSS の危険が少しでもあるサイトで、トークンを localStorage に保存する。ブラウザのセッションには httpOnly の Cookie のほうが安全です。
• aud と iss の確認を忘れる。あるサービス向けに発行されたトークンを、別のサービスに対して使い回されてしまいます。
• 短すぎる、または人が考えた HMAC シークレット。HS256 には少なくとも 256 ビット（ランダムな 32 バイト）が必要です。推測可能なシークレットは、トークン 1 つからオフラインで総当たりされる可能性があります。
どの署名アルゴリズムを選ぶべきか
• HS256（HMAC-SHA256）：1 つの共有シークレットで署名も検証も行います。シンプルで高速ですが、検証するすべてのサービスがトークンを発行することもできてしまいます。1 つのバックエンド内なら問題ありません。
• RS256（SHA-256 を使った RSA PKCS#1 v1.5）：最も広くサポートされている非対称方式です。発行者が秘密鍵を持ち、他は全員公開鍵で検証します。2048 ビットの鍵で署名は 256 バイトです。
• PS256（RSA-PSS）：RS256 と同じ鍵で、より新しいパディング方式を使います。すべての利用側が対応している場合に使いましょう。
• ES256（ECDSA P-256）：同等の安全性で、鍵がはるかに小さく、署名は 64 バイトです。新しいシステムでよく使われ、一部では必須です（Apple、WebAuthn 関連の API）。
• EdDSA（Ed25519）：高速で決定論的な署名で、対応するライブラリが増えています。ブラウザの対応は他の方式より遅れました。
関連する無料ツール
- Base64 エンコーダー / デコーダー — テキストやファイルを Base64 にエンコードし、画像を CSS や <img> のコード付きでデータ URI に変換、Base64 をプレビュー可能なファイルにデコードできます。データはブラウザの外に出ません。
- JSON 整形 — JSON を整形、圧縮（minify）、検証し、解析エラーは行と列で位置を示します。ブラウザ上で動作、アップロード不要。
- パスワード生成 — 強力なランダムパスワード、覚えやすいパスフレーズ、PIN を生成します。すべてブラウザ内で動作し、何も送信・保存されません。