JWT Debugger Advanced

A JSON Web Token (JWT) is a compact, URL-safe token format consisting of three Base64URL-encoded parts separated by dots: header (algorithm & type), payload (claims), and signature. The server signs the header+payload with a secret or private key — the receiver can verify authenticity without storing session state.

Yes — this tool runs 100% in your browser. No token data is ever sent to any server. That said, avoid pasting long-lived production tokens into any online tool as a habit. For short-lived access tokens used for debugging, this tool is completely safe.

HS256 (HMAC-SHA256) uses a single shared secret for both signing and verifying — simple but requires both parties to share the secret. RS256 (RSA-SHA256) uses a private key to sign and a public key to verify — better for distributed systems. ES256 (ECDSA-SHA256) uses elliptic curve cryptography, producing smaller signatures with equivalent security to RS256.

The 'none' algorithm means the token has no signature — any payload can be accepted as valid. Some older JWT libraries had vulnerabilities where they accepted 'alg: none' tokens, allowing attackers to forge tokens. Always explicitly reject 'none' algorithm tokens in your verification logic.

The exp (expiration) claim is a Unix timestamp. When the current time is past that timestamp, the token is considered expired and should be rejected by the server. Clients must request a new token (via refresh token or re-authentication). This tool shows exact time until expiry or how long ago it expired.

Standard claims are defined in RFC 7519: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID). Custom claims are any additional key-value pairs added by your application, like user roles, email, or tenant ID. Standard claims are highlighted differently so you can spot them instantly.