Tools Home
JWT
JWT Token DecoderInspector & Expiry

JWT Token Decoder & Expiration InspectorRFC 7519 Compliant

Inspect Header, Payload, Signature, decode exp timestamp with 100% privacy. Zero server requests, completely isolated in your browser.

0 chars
JWT Structure Anatomy
Headeralg & typ
Payloadclaims & exp
Signatureverification

Provide the shared secret to verify HMAC (HS256/384/512) signatures locally using the browser's Web Cryptography API. Zero secret data ever leaves your computer.

Paste or load a token on the left to inspect expiration & claims.

100% Client-Side Privacy

Every JWT decoding and expiration calculation is performed purely in your browser's memory using native JavaScript and Web APIs. Zero token data or cryptographic secrets are ever sent to backend servers.

Precision Expiration Clock

Real-time countdown inspection for exp, iat, and nbf timestamps. Includes localized calendar format, UTC timestamps, and visual lifetime progress indicators with second-level accuracy.

Local WebCrypto HMAC Verify

Verify HS256, HS384, and HS512 signatures directly inside your client environment using the W3C Web Cryptography API, preventing accidental disclosure of staging or production credentials.

Frequently Asked Questions & JWT Guide

Everything you need to know about JSON Web Token security, anatomy, and offline verification.

Is it safe to paste production JWT tokens into this decoder?

Yes! Unlike traditional web tools that transmit payloads to remote servers, ToolsAA operates on a 100% Client-Side Privacy architecture ('use client'). You can inspect your browser's Network tab to confirm zero HTTP requests or telemetries occur during decoding.

What is the difference between encoding and encryption?

Standard JWTs are Base64URL-encoded, not encrypted. This means anyone who intercepts the token can read the Header and Payload claims. The signature only ensures tamper-evidence, not secrecy. Never store plain passwords or sensitive PII in standard JWT claims!

How are the exp, iat, and nbf timestamps represented?

RFC 7519 specifies that NumericDate claims (exp, iat, nbf) are Unix epoch timestamps expressed in seconds (not milliseconds). Our inspector translates these into your local machine timezone and UTC ISO strings automatically.

Why does signature verification require a secret or certificate?

The signature is calculated as HMACSHA256(base64Url(header) + '.' + base64Url(payload), secret). Without the correct shared secret (for HMAC) or public certificate (for RSA/ECDSA), the signature cannot be validated.

Technical Reference & Architecture Guide

JWTトークンデコーダー&セキュリティインスペクター — Reference Guide

JSON Web Token(JWT)をデコードし、ヘッダーとペイロードのクレームを解析。有効期限の自動計算や署名検証をブラウザ上で安全にローカル実行します。

Key Parameters & Controls

入力JWTトークンstring

クライアントサイドでのJWTデコードおよびセキュリティ検証処理において、解析対象となるJWT文字列を指定・設定します。

Default: プリセットサンプル
HMACシークレット鍵string

クライアントサイドでの暗号署名検証において、HMAC署名(HS256/HS384/HS512)の検証に使用する共有シークレットキーを設定します。

Default: プリセットサンプル
HMAC検証ステータスstring

クライアントサイドにおける暗号署名の検証結果および実行状態(待機中 idle、有効 valid、署名不一致 invalid など)を示します。

Default: 待機中
基準現在時刻configuration

トークンの有効期限(exp)や有効開始日時(nbf)の判定基準となる現在時刻を設定し、リアルタイムに残存有効時間を計算します。

Default: 自動取得

Pro Tips & Best Practices

クレーム辞書・仕様のクイック確認

RFC 7519規格に基づく標準クレーム(iss、sub、aud、exp、nbf、iat、jti)のセマンティクスと、カスタムペイロード定義を即座に参照して権限やロール設計を監査できます。

JWTセキュリティ&衛生性(Hygiene)監査

暗号化アルゴリズムの強度(脆弱な「none」アルゴリズムの検知など)、有効期限(exp)の設定状況、機密クレームの漏洩リスクを自動で静的検査します。

100% クライアントサイドでのプライバシー保護

すべてのJWTデコード、署名検証、有効期限計算はブラウザのメモリ内(Web APIsおよびJavaScript)でのみ実行されます。トークンデータや暗号シークレット鍵がバックエンドサーバーへ送信されることは一切ありません。

Common Gotchas & Troubleshooting

JWTトークンデコーダー上で予期しない出力やバリデーション警告が表示される

入力されたトークンがドット(.)で区切られた3つのBase64URLエンコード文字列(ヘッダー.ペイロード.署名)の形式を満たしているか確認してください。組み込みのサンプルプリセットを読み込んで構造フォーマットを比較することをおすすめします。

署名検証の結果が対象の実行環境(バックエンド等)と一致しない

JWTデコーダーに入力したHMACシークレット鍵の設定を確認してください。シークレット文字列のエンコーディング(UTF-8、Base64、Hexなど)、末尾の改行コード、対象ランタイムで使用されているアルゴリズム仕様(HS256/HS384/HS512)が一致しているか検証してください。

Frequently Asked Questions

本番環境のJWTトークンを貼り付けてデコードしても安全ですか?▼

はい、安全です。ペイロードを外部サーバーへ送信する従来のWebツールとは異なり、ToolsAAは100%クライアントサイドで処理するプライバシー重視アーキテクチャ('use client')で動作します。ブラウザの開発者ツールで「ネットワーク」タブを確認すれば、デコード処理中に外部へのHTTPリクエストやテレメトリ送信が一切発生しないことを検証できます。

JWTにおける「エンコード」と「暗号化」の違いは何ですか?▼

標準的なJWT(JWS)はBase64URLで「エンコード」されているだけであり、「暗号化」されていません。そのため、トークンを傍受した第三者はヘッダーとペイロードのクレームをそのまま平文として読み取ることができます。電子署名は改ざん検知(完全性)と送信元検証のみを保証し、機密性を保つものではありません。平文パスワードや機密性の高い個人情報(PII)を標準JWTのクレームに含めないでください。

exp、iat、nbf などのタイムスタンプクレームはどのように表現されますか?▼

RFC 7519規格において、NumericDateクレーム(exp: 有効期限、iat: 発行日時、nbf: 有効開始日時)はミリ秒単位ではなく、秒単位のUnixエポックタイムスタンプとして定義されています。本インスペクターはこれらの数値を自動的に変換し、お使いの端末のローカルタイムゾーンとUTC形式のISO 8601日時文字列の両方で分かりやすく表示します。

なぜ署名検証にシークレット鍵や証明書が必要なのですか?▼

JWTの署名は「HMACSHA256(base64Url(header) + '.' + base64Url(payload), secret)」のように算出されます。正しい共有シークレット(HMACの場合)または公開鍵証明書(RSA/ECDSAの場合)がなければ、署名が正規の発行者によって生成されたものか、またペイロードが改ざんされていないかを数学的に検証できないためです。

Related Tools & Utilities

All Tools →