Decode JSON Web Tokens to inspect the header and payload. Detects expired tokens, displays issuance and expiration times in human-readable form. 100% browser-based — your tokens never leave your device.
A JSON Web Token (JWT) is a compact, URL-safe way to transmit claims between two parties. JWTs are everywhere in modern web authentication: OAuth flows, single sign-on (SSO), API authentication, and microservice communication all commonly use them.
A JWT consists of three parts joined by dots: header.payload.signature. The header and payload are base64url-encoded JSON. The signature is a cryptographic signature over the header and payload, using either an HMAC secret (symmetric) or an RSA/ECDSA key (asymmetric).
JWTs are not encrypted by default — they're encoded. Anyone with the token can decode and read the contents. The signature only prevents tampering: changing the payload invalidates the signature, but the original payload is readable. This is a common source of security misunderstanding.
The signature is shown but not verified. Verification requires the secret key (for HMAC) or public key (for RSA/ECDSA), which you should never paste into a website. To verify signatures, use a server-side library or self-hosted tool.
Tiny JSON describing the token type (typ: "JWT") and the signing algorithm (alg). Common algorithms: HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), ES256 (ECDSA).
The claims — facts the token asserts. Standard claims (defined in RFC 7519): sub (subject/user ID), iss (issuer), aud (audience), exp (expiration), iat (issued at), nbf (not before), jti (token ID). Custom claims can be added freely.
Cryptographic proof the token wasn't modified after being issued. For HMAC: HMACSHA256(base64url(header) + "." + base64url(payload), secret). For RSA/ECDSA: a signature using the private key. Verifying the signature requires the matching secret or public key.
exp on every use. JWT libraries usually do this automatically, but if you're hand-rolling validation, expiration is the most commonly missed check.alg on the server. A well-known vulnerability: an attacker sets alg: "none" and supplies an unsigned token. The server, if not careful, accepts it. Always validate the algorithm matches what your application expects.kid (key ID) that identifies which signing key was used.exp claim in the payload — it's a Unix timestamp (seconds since 1970-01-01 UTC). Compare it to the current time. Our decoder does this automatically and shows EXPIRED in red if applicable. Note: a future exp doesn't mean a token is valid — it just means it hasn't expired yet. You still need to verify the signature on the server.alg field mean?HS256 (HMAC with SHA-256, symmetric, used when the same party signs and verifies), RS256 (RSA with SHA-256, asymmetric, used when the verifier doesn't have the signing key — common for SSO), ES256 (ECDSA with SHA-256, asymmetric and faster than RSA). Less common: HS384, HS512, RS384, RS512, PS256, EdDSA.localStorage is convenient but vulnerable to XSS. httpOnly cookies are safer against XSS but vulnerable to CSRF without proper CSRF tokens. Modern best practice: short-lived access tokens in memory (lost on tab close, refreshed via a long-lived httpOnly refresh token cookie). Never store JWTs in URL query parameters — they get logged everywhere.exp?jti); (2) use short-lived tokens (5-15 minutes) so revocation propagates fast; (3) check a database on every request (which defeats the stateless benefit). Most production systems combine #2 and #1.