JWT Decoder
Paste a JSON Web Token to read its header and payload, see when it expires, and understand every claim. Your token never leaves your browser.
Runs in your browserNo sign-upNothing uploaded
Decoding is not verification. Anyone can read a JWT's header and payload, because they are only base64url-encoded. This tool shows what the token claims; it does not prove the token is genuine. Always verify the signature on your server.
Header
Payload
Claims explained
Verify signature (optional, HS256/HS384/HS512)
Checks an HMAC signature with a secret you enter, using your browser's Web Crypto API. The secret never leaves this page. RSA/ECDSA tokens need the issuer's public key and are not verified here.
How to use the JWT Decoder
- Paste the token into the Encoded token box. A leading
Bearerfrom an Authorization header is ignored. - The header and payload are decoded instantly and shown as formatted JSON.
- Read the Claims explained table:
exp,iatandnbfare converted to dates with “expires in” / “expired ago” times. - Check the status bar for expiry problems and the warnings for risky settings such as
alg: none. - Optionally enter the shared secret to verify an HS256, HS384 or HS512 signature locally.
What is inside a JWT?
A JSON Web Token (RFC 7519) is three base64url strings joined by dots: header.payload.signature. The header names the signing algorithm (alg) and token type. The payload holds the claims, such as who the user is and when the token expires. The signature is computed over the first two parts with a secret or private key.
Decoding is not verifying
The header and payload are only encoded, not encrypted, so anyone holding the token can read them. That is why you should never put passwords or secrets in a JWT payload. Decoding tells you what a token says. Verifying the signature, normally on your API server with a library such as jose or PyJWT, proves who issued it and that it has not been modified. A server must also check exp, nbf, iss and aud, and reject unexpected algorithms.
Registered claims cheat sheet
| Claim | Meaning |
|---|---|
iss | Issuer: who created and signed the token |
sub | Subject: usually the user ID |
aud | Audience: which API the token is meant for |
exp | Expiration time, in seconds since the Unix epoch |
nbf | Not valid before this time |
iat | Issued-at time |
jti | Unique token ID, useful for revocation lists |
Debugging “token expired” errors
If an API rejects a token that looks fresh, compare exp and nbf with the server clock. Small clock skew between machines is common, so most libraries allow 30-60 seconds of leeway. Also check that exp is in seconds: a millisecond value is a frequent bug and puts expiry thousands of years in the future.
Frequently asked questions
Is it safe to paste a production JWT here?
Does this tool verify the JWT signature?
Why does my token show as expired?
exp claim is in the past compared with your computer’s clock. Request a new token, or refresh it with your refresh token. If the times look wrong, check for clock skew or an exp value written in milliseconds.What is the difference between JWT, JWS and JWE?
Why is alg “none” dangerous?
alg: none and should only accept the specific algorithm they expect.