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.
Frequently asked questions
Ship API docs that stay this clean
Specway turns your OpenAPI spec into a branded developer portal — auto-synced, searchable, with built-in playground and code samples in every language. Free tier available.