JWT Decoder
Paste any JSON Web Token and instantly inspect its header, payload claims and expiry — decoded in your browser, your token never leaves your machine.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64url-encoded sections separated by dots: a header (algorithm + token type), a payload (claims — facts about the user or session), and a signature that proves the token hasn't been tampered with.
JWTs are used everywhere for authentication and authorization — your login session, OAuth access tokens, API keys. When a bug bites in production (wrong role, token expired, missing claim), you need to see inside the token fast. That's exactly what this tool does.
The signature cannot be verified here without the secret key — that must always happen server-side. But the header and payload are plain JSON that any tool can read, and since they're Base64url-encoded (not encrypted), it's safe to decode them anywhere.
How to decode a JWT
- 1
Copy your JWT
Grab the token from your browser DevTools (Application → Cookies or Local Storage), your API response, or your terminal.
- 2
Paste it into the field
The token is decoded instantly as you type. You'll see the header, payload, and raw signature.
- 3
Inspect the claims
Check exp for expiry, sub for the subject, roles or permissions for authorization claims.
Why developers use a JWT decoder
Debug auth issues instantly
See exactly what claims are in the token — wrong role, missing scope, or expired exp are immediately obvious.
Catch expired tokens
The expiry badge shows whether the token is still valid and how much time remains or has elapsed.
Verify the algorithm
Confirm your server is using RS256 (asymmetric) instead of the insecure none or HS256 with a weak secret.
Privacy-safe
Your token never leaves the browser. No logs, no analytics on token content — everything runs in JavaScript locally.
JWT security — what you should know
- Never trust the client-side decoded payload without verifying the signature server-side. A malicious actor can craft any payload they want — the signature is the only thing that proves authenticity.
- Watch out for the
alg: "none"attack — some old libraries accept tokens with no algorithm and skip signature verification. Always enforce a specific algorithm on your server. - Short-lived tokens (15–60 minutes) with refresh token rotation are safer than long-lived JWTs. Check your
expclaim is reasonable. - Don't store JWTs in
localStorage— prefer HttpOnly cookies to protect against XSS.
Frequently asked questions
No — and that's by design. Signature verification requires the secret key (HS256) or public key (RS256/ES256). Those must never be exposed to a browser. Decoding the payload is safe; verifying authenticity must happen on your server.
Yes. The entire decoding happens inside your browser — no network request is made. The token never reaches any server. Still, treat tokens like passwords: don't share them unnecessarily.
sub (subject — user ID), iss (issuer — who created it), aud (audience — intended recipient), exp (expiration time — Unix timestamp), iat (issued at — when it was created), nbf (not before — earliest valid time), jti (JWT ID — unique identifier).
An unsecured JWT (alg: none) has an empty signature section, leaving a trailing dot. This format should never be accepted in production — it bypasses signature verification.
Base64url replaces + with - and / with _ and omits padding (=). This makes the token safe to use directly in URLs and HTTP headers without percent-encoding.
Need another tool?
Browse the full toolbox or dig into the blog for the engineering behind it.