JWT Decoder
Inspect a JSON Web Token’s header and claims.
Decoding is not verification
Decodes as you type. A Bearer prefix is ignored.
Something went wrong
This token uses alg: none
It carries no signature at all. Any system that accepts this token is trusting
data that anyone could have written. Reject none explicitly in your
verification code.
| Claim | Value |
|---|
Shown as-is. Checking it would require the signing key, which you should never paste into a web page.
Processed locally in your browser. Nothing you type here is sent to our servers.
What is a JWT?
A JSON Web Token is three base64url-encoded segments joined by dots:
header.payload.signature. The header says which algorithm signed the
token, the payload carries the claims, and the signature lets a server confirm that
neither of the first two has been altered.
The important consequence: the payload is encoded, not encrypted. Anyone holding a token can read every claim in it, exactly as this page does. Never put anything in a JWT that the bearer should not see.
Decoding versus verifying
Decoding splits the token and base64url-decodes it. Verifying recomputes the signature with the signing key and checks it matches. They are completely different operations, and only the second tells you anything about authenticity.
This tool only decodes, deliberately. Verifying here would mean either asking you to
paste a production signing secret into a web page, or sending your token to a
server — and we are not going to do either. Verification belongs in your
application, using a library that also checks exp, nbf,
iss, aud, and that the algorithm is the one you expect.
How to use it
- Paste your token into the field above. A
Bearerprefix is stripped automatically. - The header, payload and claims appear immediately.
- Check the badges for expiry status, issue time and key ID.
- Copy the header or payload JSON if you need it elsewhere.
The registered claims
iss— issuer, who created and signed the token.sub— subject, who the token is about, usually a user ID.aud— audience, which service is meant to accept it.exp— expiry. Seconds since the Unix epoch, not milliseconds.nbf— not before. The token is invalid until this time.iat— issued at, when the token was created.jti— a unique ID, used to prevent replay.
All the time claims are NumericDate values in seconds. Passing one to a
JavaScript Date without multiplying by 1000 lands you in January 1970,
which is a mistake worth recognising on sight.
Common use cases
- Working out why an API is returning 401 — checking whether the token has simply expired.
- Confirming which scopes or roles a token actually carries.
- Checking the
audandissvalues during an OAuth integration. - Reading the
kidto identify which key was used, during a key rotation.
Limitations and safety
- No signature verification. A tampered token decodes just as happily as a genuine one.
- Encrypted tokens (JWE, five segments) are not supported. This tool handles signed tokens (JWS, three segments).
- Expiry is judged against your device's clock. If that is wrong, the verdict is wrong.
- Treat any token you paste as compromised if the machine is not yours. Nothing is transmitted from this page, and nothing is stored — but a token on screen is a token someone could read over your shoulder.