JWT Decoder
See what's inside a JSON Web Token — header, claims, expiry.
What a JWT actually contains
A JSON Web Token looks like random noise but is really three base64url-encoded parts joined by dots: a header (algorithm and type), a payload (the claims — user id, roles, issuer, expiry) and a signature. This decoder reveals the first two so you can see exactly what your backend is putting into tokens, or debug why an API treats you as the wrong user.
The expiry claim (exp) is translated into a human-readable date with a clear expired/valid indicator — the single most common cause of "invalid token" errors during development.
Decoding happens entirely in your browser with atob and JSON parsing. The signature is not verified — that requires the secret or public key and should happen on your server. Never trust a decoded payload without signature verification.
FAQ
Is pasting a JWT here safe?
Nothing is transmitted — decoding is local. Still, treat tokens as sensitive: don't paste production tokens into any tool on a shared machine.
Why is the payload called "claims"?
Because the payload asserts facts about the bearer: "this is user 42", "they have admin role", "this is valid until noon". The server decides whether to trust those claims after verifying the signature.
Can I modify a decoded JWT to change my role?
Changing the payload invalidates the signature. Unless the server skips verification (a critical bug), the token will be rejected — which is exactly the point of signing.