Paste any JWT token to instantly decode and display the header, payload claims and expiry. All processing is done in your browser — your token is never sent to a server.
JWT Decoder
Decodes a JSON Web Token and shows the header, payload, expiry, issuer and subject — no signature verification, purely inspection. Entirely client-side, so it's safe to paste a real token into while debugging, without it ever touching a server.
What's actually inside a JWT
A JWT is three Base64URL-encoded segments joined by dots, defined by RFC 7519, and used constantly for auth and authorisation across REST APIs, SPAs, microservices and OAuth 2.0 flows:
- Header — token type and signing algorithm (HS256, RS256, etc.)
- Payload — the actual claims:
sub,iss,exp,iat, plus whatever custom claims the issuer added - Signature — proves the token wasn't tampered with, but verifying it requires the secret or public key, which is exactly why decoding and verifying are two separate things
Worth saying plainly: decoding is not the same as trusting
Anyone can decode a JWT and read every claim inside it — that's by design, not a bug, since Base64 isn't encryption. What actually stops someone from forging a token is signature verification, and that has to happen server-side against the real secret or public key. If your application is trusting a JWT's contents just because it decoded cleanly, without checking the signature, that's a real vulnerability, not a theoretical one.
Practices worth following if you're issuing tokens
- Short expiry on access tokens (15 minutes is a common baseline) paired with a longer-lived refresh token
- RS256 over HS256 for anything public-facing — asymmetric signing means only the private key can sign, while any number of services can verify with the public key, which matters once more than one service needs to check tokens
- Never store JWTs in localStorage if you can avoid it — an XSS vulnerability anywhere on the page can read localStorage directly. httpOnly cookies are the safer default.
- Always validate
issandaudserver-side, not just the signature and expiry — a validly-signed token issued for a different service shouldn't be accepted just because the signature checks out