JWT Decoder at a glance
- What it does
- Decode a JSON Web Token to read its header, payload and expiry.
- Where it runs
- Entirely in your browser — no data is uploaded
- Works offline
- Yes, once the page has loaded
- Cost
- Free, with no account and no usage limit
- Category
- Developer & Code
How to use the JWT decoder
- Paste the token, with or without a
Bearerprefix. - Read the header to see the algorithm (
alg) and, if present, the key ID (kid) that identifies which public key verifies it. - Read the payload for the claims - who the token is about, who issued it, what it grants and when it expires.
- Check the timestamps.
exp,iatandnbfare Unix seconds; the timestamp converter turns them into dates.
What the standard claims mean
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who minted the token. Your API must check this matches the identity provider you trust. |
sub | Subject | Who the token is about - normally a stable user ID. |
aud | Audience | Which service the token is intended for. Reject tokens addressed to someone else. |
exp | Expiry | Unix time after which the token must be rejected. |
nbf | Not before | Unix time before which the token is not yet valid. |
iat | Issued at | When the token was created. Useful for enforcing a maximum age. |
jti | JWT ID | A unique identifier, used to blocklist individual tokens. |
Everything else is application-specific: scope, roles, email, tenant identifiers and so on.
What a decoder cannot tell you
Decoding is not verifying. Reading the payload proves only that someone produced a string in the right shape. A token is trustworthy only when your server has checked the signature against the issuer's key, and then checked exp, iss and aud.
Never put secrets in a payload. The claims are Base64, not encryption - any user holding their own token can read every field in it. Internal notes, feature flags you would rather not expose, and anything resembling personal data all leak this way.
Two implementation mistakes worth knowing. The alg: none attack: a library that honours the header's algorithm claim can be handed an unsigned token and told to accept it - always pin the expected algorithm server-side. And algorithm confusion: a token signed with HMAC using the server's own RSA public key as the shared secret, accepted by a library that infers the algorithm from the header rather than from configuration.
Expiry and refresh
Because a JWT is validated by signature alone, there is no central record to revoke. A stolen token stays valid until it expires, which is why access tokens are usually short-lived - 5 to 15 minutes is typical - and paired with a long-lived refresh token that is stored server-side and can be revoked.
If you need immediate revocation for access tokens, you need a blocklist keyed on jti, which reintroduces the shared state JWTs were meant to avoid. That trade-off is the main reason some teams stay with opaque session tokens.
Frequently asked questions
The decoding is done locally in your browser and nothing is transmitted or stored. Even so, treat any token you have pasted into any tool as exposed if you cannot be certain of that page's behaviour - the safest habit is to use a test token, or rotate afterwards.
No. Verification requires the issuer's secret or public key, which is exactly what should never be shared with a web page. Verify server-side using your identity provider's JWKS endpoint.
That is the signature - raw bytes from HMAC or a public-key algorithm, Base64url encoded. It is not text and will not decode into anything meaningful.
A standard signed JWT (JWS) is not. There is a separate encrypted form, JWE, which has five segments instead of three and whose payload genuinely is unreadable without the key. Almost every token you meet in the wild is JWS.
Key ID. It tells the verifier which of the issuer's published keys signed this token, so the issuer can rotate keys without invalidating tokens still in flight.
Nothing you enter here leaves your browser
JWT Decoder does its work in JavaScript running on your own device. The page loads once, and after that there is no upload step and no server involved — which matters here because API responses, tokens and configuration files are exactly the kind of thing that should not be posted to someone else’s server for formatting.
You can verify this rather than taking our word for it: load the page, disconnect from the internet, and the tool keeps working. Our privacy policy sets out what is and is not collected, and this guide explains why the distinction matters.