JWT Decoder (2026)
Decode JWT tokens to inspect header and payload. Detects expired tokens. Runs entirely in your browser — no upload, no logging. Signature is shown but not verified (verify server-side with your secret).
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 9999999999
}What a JWT actually is
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature.
The header declares the signing algorithm and token type. The payload carries claims — standard ones (iat, exp, sub, iss) plus whatever custom data the issuer attached. The signature is a cryptographic hash over header+payload, computed with a shared secret (HS256) or a private key (RS256/ES256).
The point of the signature is that anyone with the public key (or shared secret) can verify the token wasn't tampered with — without a database lookup. That's what makes JWTs "stateless."
Decoding ≠ verifying
This tool decodes — it splits, base64url-decodes, and shows you the claims. It does not verify the signature. Verification requires the secret (HS256) or public key (RS256/ES256), which you should never share with a browser tool.
On your server, every JWT-protected route should verify before trusting any claim. Use a battle-tested library — jsonwebtoken, jose, PyJWT — never roll your own. Common mistakes (accepting alg: none, mixing HMAC verification with an asymmetric key) have been weaponized for a decade.
Standard claims you should know
- iat (issued at) — Unix seconds when the token was created.
- exp (expiration) — Unix seconds when the token stops being valid. The decoder shows relative time (e.g. "expires in 12m").
- sub (subject) — who the token is about. Typically a user ID.
- iss (issuer) — who issued the token. Verify this matches your auth server.
- aud (audience) — who the token is for. Verify this matches your service identifier.
- nbf (not before) — Unix seconds before which the token is invalid (rarely used).
- jti (JWT ID) — unique identifier for revocation lookup.
Sensible token lifetimes
Access tokens: 5–60 minutes. Short because you can't revoke a stateless JWT mid-flight — if a token leaks, you live with it until exp.
Refresh tokens: days to weeks. Stored server-side or in a httpOnly cookie. Used to mint new access tokens. Rotate on every use.
If your access tokens are 24h+, you're trading security for convenience. Build refresh rotation instead — modern client SDKs (NextAuth, Clerk, Auth0) handle it for you.