JWT デコーダー
エンコードと暗号化 · 無料オンラインツール
JWT トークンをデコードしてヘッダーとペイロードを確認。
3 部構成
JWT は header.payload.signature で、各部分は base64url エンコードされています。このツールは 3 つすべてを分割・デコードします。
時間クレーム
標準クレーム exp、iat、nbf は人が読める日付で有効状態とともに表示されます。
デコードのみ
このツールはトークンをデコードして表示するだけです — 署名の検証は行いません。クレームを信じる前に必ず検証してください。
JWT デコーダーの使い方
- 1Enter or paste your data into the input field.
- 2Select the desired encoding, hashing, or encryption options.
- 3Click the action button to process your data.
- 4Copy the result from the output field.
機能と特徴
- ✓完全無料 — 登録不要、サブスクリプションなし、広告なし
- ✓ブラウザ上で完全に動作 — データは端末から送信されません
- ✓高速・軽量 — 即座に結果を表示
- ✓クロスプラットフォーム — デスクトップ・タブレット・モバイル対応
JWT デコーダーとは？
JSON Web Token (JWT), defined by RFC 7519, is a compact, URL-safe token format for securely transmitting claims between parties. A JWT consists of three Base64URL-encoded parts separated by dots: Header.Payload.Signature. It is widely used for API authentication, OAuth 2.0, and SSO.
JWT デコーダーの仕組み
The Header specifies the signing algorithm (e.g., HS256, RS256). The Payload contains claims (registered, public, private) — statements about an entity. The Signature is computed over the encoded Header and Payload using the algorithm and a secret/private key. To verify, recompute the signature and compare.
よくある使用例
- ✓API authentication — bearer tokens in Authorization headers
- ✓OAuth 2.0 — access tokens and ID tokens
- ✓SSO — share identity across multiple services
- ✓Stateless sessions — store user info without server-side sessions
JWT vs Session Cookies
Sessions store state server-side; JWTs are stateless and self-contained. JWTs scale better (no session store) but are harder to revoke before expiry. Sessions are more secure for sensitive apps (can revoke instantly); JWTs suit distributed/microservice architectures. Always use HTTPS for both.
セキュリティとプライバシー
This tool decodes JWTs locally in your browser — your token never leaves your device. IMPORTANT: Decoding a JWT only reads its contents; it does NOT verify the signature. Never trust JWT claims without server-side signature verification. JWTs are visible to anyone who intercepts them — use HTTPS.
技術的な詳細
Standard: RFC 7519. Structure: Base64URL(Header).Base64URL(Payload).Base64URL(Signature). Header: alg (HS256/RS256/ES256/none), typ. Registered claims: iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at), jti (JWT ID). Signature: HMAC(SHA-256) for HS256, RSA for RS256. 'alg: none' tokens must always be rejected.
よくある質問
Is decoding a JWT the same as verifying it?
No. Decoding reads the payload; verification checks the signature cryptographically. Anyone can decode a JWT; only the server with the secret can verify it. Never trust unverified JWT claims.
What is the 'alg: none' vulnerability?
If a server accepts 'alg: none' tokens, attackers can forge tokens without a signature. Always reject 'none' algorithm and use a hardcoded allowed-algorithms list.
How long should a JWT live?
Access tokens: 15-60 minutes. Refresh tokens: days to weeks. Short-lived access tokens limit damage if leaked. Use refresh tokens to maintain sessions.