JWTエンコーダー&デコーダー:JSON Web Token を瞬時に解析・生成
ブラウザ上でJWTをすぐにデコードするか、組み込みエンコーダーで自身のトークンを作成できます。ヘッダー、ペイロードと分かりやすいクレームの解説、有効期限やカウントダウンを表示。ログインやアカウント登録は不要で、データが外部に送信されることはありません。
最終更新: 2026年4月
100%無料&プライベート
ブラウザ内ですべて処理します。サーバへのアップロードはありません。登録不要です。
JSON Web Token (JWT) とは?
JWTは、送信者と受信者間で情報を安全にやり取りするための、RFC 7519で定義されたオープン標準です。ステートレスな認証に非常に有用であり、クライアント情報をサーバーのデータベースで毎度照会する手間を省くことができます。
一般的なJWTは「ドット ( . )」で区切られた3つのBase64url文字列のブロックで構成されます:
ヘッダー (Header)
typ)と、改ざん防止に使用されたハッシュ署名アルゴリズム(alg: HS256等)を記述したメタデータです。ペイロード (Payload)
署名 (Signature)
ペイロードの中身を第三者から隠したい場合は、JWTではなく暗号化プロトコルである JWE (JSON Web Encryption) の利用を検討してください。
ツールの使い方
- ご利用のAPI、または開発者ツールからJWTを取得します
- ページ上部のテキストエリアに文字列を直接貼り付けます
- 自動的に解析され、ペイロードがJSON形式として表示されます
- トークンの有効/無効状態が時間ステータスで表示されます
- 問題がないかセキュリティ監査を確認してください
- 詳細なクレーム(Claims)一覧を解析します
- 検証用のバックエンドソースコードをコピーして活用します
JWTの標準クレーム (Registered Claims) の解説
- sub - Subject (sub): JWTが対象とする主体の識別子です。一般に一意のユーザーIDを指定します。
- iss - Issuer (iss): このJWTを発行したサーバーやサービス(システム)の名前です。
- aud - Audience (aud): JWTを受け取り、認証する権限を持つ対象者(API等)です。
- exp - Expiration Time (exp): トークンが無効になるUNIX時間。非常に重要なセキュリティ指標です。
- iat - Issued At (iat): このJWTが発行された時点のUNIX時間です。
- nbf - Not Before (nbf): この時間より前にはトークンを受け入れてはならないという待機時間です。
- jti - JWT ID (jti): リプレイ攻撃を防止するための、トークン固有の推測不可能なIDです。
サーバーセッション vs JWT : どう使い分けるか?
| JWT (Stateless) | Session Token (Stateful) | |
|---|---|---|
| バックエンドのストレージへの依存 | なし | 必ず必要 (RedisやDB) |
| クラウドやマイクロサービスとの相性 | 極めて良好。スケールに強い | 共有が難しくスケールに弱い |
| 強制ログアウトの即効性 | 期限切れを待つか複雑な仕組みが必要 | DBから消すだけで即座に無効化可能 |
| 通信データ容量 | 大きくなりがち (HTTPヘッダーを圧迫) | 非常に小さい |
| 最も推奨される環境 | ステートレスAPI, サーバーレス, マルチデバイス | 厳格な権限管理が必要な従来のモノリスWeb |
| 情報漏洩への耐性 | 有効期限が切れるまで攻撃者が権限を保持してしまう | 被害後すぐにセッションを破棄して防御可能 |
JWTが適切なケース: APIサーバーの負荷を下げたい場合や、独立した複数のシステムでパスを共用したい場合。
セッションが適切なケース: 強制的なアカウントロックや高頻度な権限更新が生じる金融系システムなど。
署名アルゴリズム (RS256 vs HS256)
| Algタグ | 暗号化ファミリー | 鍵と強度の特徴 | 主な使用ケース |
|---|---|---|---|
| HS256 | HMAC-SHA256 | 対称鍵 (共通鍵) | 外部と鍵を共有しない単一サーバー構成用 |
| RS256 | RSA-SHA256 | 非対称 (公開鍵/秘密鍵) | 外部APIや複数のサービスがトークンを検証する場合 |
| ES256 | ECDSA P-256 | 非対称 (楕円曲線) | モバイル環境やIoTなどで高速性が重視される場合 |
| PS256 | RSA-PSS SHA256 | 非対称 (高度なパディング) | 最高峰のセキュリティが求められる場合 |
| none | なし (None) | セキュリティ一切なし | ⛔ 極めて危険。検証機能の回避(バイパス)に使用されるため運用禁止 |
原則 RS256 以上の非対称暗号を推奨します。秘密鍵を認証サーバーだけが保持し、他のシステムは公開鍵で検証のみを行う構成が理想的です。
JWT 運用における最重要ベストプラクティス (2026年版)
- JWTの電子署名を受信するバックエンドは、常に信頼できるライブラリで独自に検証を行ってください。
- トークンの「有効期限(exp)」は15〜30分程度の非常に短い時間に設定します。
- ペイロードはBase64でエンコードされているだけです。個人情報や機密データは絶対に含めないでください。
- JWTの転送には、必ずHTTPS / TLS化されたセキュアなネットワークを利用してください。
- ブラウザにトークンを保存する場合は、LocalStorageではなく「httpOnly属性」付きのCookieを使用し、XSS攻撃を軽減してください。
- アクセストークンと、より長寿命なリフレッシュトークンを組み合わせてセッションを管理してください。
- 他システムへの流用を防ぐため、必ず「対象者(aud)」と「発行者(iss)」が自システムのものか検証してください。
- アルゴリズムが「none」のJWTは検証システム内で無条件にブロックしてください。
- 万が一に備え、被害を食い止めるためのトークン無効化リスト(Denylist)をバックエンドに構築してください。
バックエンドへ導入するための検証コードスニペット
ご自身の開発環境へ組み込んで活用してください。
Node.js スクリプト
// Decode without verification (read-only, same as this tool)
function decodeJWT(token) {
const [header, payload] = token.split('.');
const decode = str => JSON.parse(atob(str.replace(/-/g, '+').replace(/_/g, '/')));
return { header: decode(header), payload: decode(payload) };
}
const { header, payload } = decodeJWT(yourToken);
console.log(payload.exp); // expiry timestampPython 環境
import base64, json
def decode_jwt_payload(token):
payload = token.split('.')[1]
# Add padding
payload += '=' * (4 - len(payload) % 4)
return json.loads(base64.urlsafe_b64decode(payload))
claims = decode_jwt_payload(your_token)
print(claims['exp']) # expiry timestampGo 言語
import (
"encoding/base64"
"encoding/json"
"strings"
)
func decodeJWTPayload(token string) (map[string]interface{}, error) {
parts := strings.Split(token, ".")
payload, _ := base64.RawURLEncoding.DecodeString(parts[1])
var claims map[string]interface{}
json.Unmarshal(payload, &claims)
return claims, nil
}JWTの真の存在意義
JWTの最大の強みは「ステートレス」である事実です。データベースへの問い合わせを行わずとも情報を信頼できるため、大規模に分散された最新のAPIゲートウェイには欠かせない技術です。
Frequently Asked Questions
JWTとはそもそも何ですか?
情報をJSON形式で安全に伝達するためのWeb標準プロトコルです。署名によりデータの完全性が保証されています。
どのようにデコードされるのですか?
当サイトを通すと、Base64Urlでエンコードされた文字列をJavaScriptで単純にデコードし、本来のJSONオブジェクトを展開します。
秘密鍵がなくてもデコードできるのですか?
はい。JWTは暗号化ではなく「エンコード」されているだけであるため、秘密鍵なしでペイロードの中身を誰でも読むことができます。秘密鍵が必要になるのは「改ざんされていないかの確認(署名検証)」のみです。
ここでトークンを解析してセキュリティ上のリスクはありませんか?
リスクはゼロです。EveryToolの当機能は完全にブラウザ内(クライアントサイド)のみで動作しており、トークンが外部へ送信されることは一切ありません。
有効期限(Exp)の確認方法は?
ペイロード内の「exp」プロパティをリアルタイムで監視しており、UNIXタイムを超過すると画面に期限切れのアラートを表示します。
エンコードとデコードの違いは?
エンコードはJSONと署名をBase64で長い文字列の塊に結合すること。デコードはその文字列から人間が読める元のJSONを抽出することです。
「alg: none」の脆弱性とは何ですか?
アルゴリズムを意図的に空にしてサーバーの検証機能をバイパスする攻撃手段です。利用するライブラリ側で対策を行う必要があります。
機密情報はペイロードに含めていいですか?
絶対に含めてはいけません。パスワードやクレジットカード番号を入れてしまうと、誰もがデコードして盗み見ることが可能です。
「nbf (Not Before)」クレームとは?
設定された日時よりも前には、そのトークンを使用してはいけないというシステムへの待機命令です。
「iat」と「exp」の違いは?
iatはトークンが生成された誕生日。expはトークンが失効する終了(死亡)時刻です。
HTTPで使用できますか?
本番環境では絶対にHTTPSを利用してください。プレーンなHTTPではネットワークの途中でJWTを容易に盗聴されます。
JWSやJWEとの関連性は?
現在一般に使われているJWTのほとんどは、署名によって改ざんのみを防ぐ「JWS形式」です。データの中身自体を見えないように暗号化したい場合は「JWE形式」を使用します。
標準化されていないデータを追加してもいいですか?
もちろんです。権限(role)やユーザーネームなど、独自の「プライベートクレーム」を自由に追加してシステム設計に役立ててください。