What is a JWT?
Reviewed by Prabath Thalangama · Last updated
A JSON Web Token (JWT) is a compact, signed token made of three Base64URL parts separated by dots: a header naming the signing algorithm, a payload of claims such as the user ID and expiry time, and a signature. This decoder shows the header and payload as readable JSON and converts the exp and iat timestamps to dates.
Decoding happens entirely in your browser; the token is never sent to a server. Even so, treat production access tokens like passwords and prefer pasting expired or test tokens.
Decoding is not verification. Anyone can read a JWT's payload because it is only encoded, not encrypted. The signature, shown here as unverified, proves the token was issued by someone holding the key, and only your server can check that.
How do I decode a JWT?
- Paste the token, the long string that starts with eyJ, often found after 'Bearer ' in an Authorization header.
- Read the header (alg, typ, kid) and the payload claims.
- Check the expiry date to see whether the token is still valid.
How to read the results
- Header
- alg is the signing algorithm (HS256, RS256, ES256...), typ is usually JWT, and kid identifies which key signed it.
- Payload
- The claims: iss (issuer), sub (subject, usually the user), aud (audience), exp (expiry), nbf (not before), iat (issued at) and any custom claims.
- Expiry
- exp and iat converted from Unix timestamps to dates, and whether the token has already expired.
- Signature (unverified)
- The third part of the token. It is displayed but not checked, because checking needs the secret or public key.
JWT security pitfalls
Trusting a token without verifying the signature
Always verify the signature with your key and check exp, nbf, iss and aud on the server before trusting any claim.
Accepting alg: none or switching algorithms
Configure the verifier with the exact algorithm you expect. Libraries that read the algorithm from the token's header have been tricked into accepting unsigned tokens (alg: none) or into verifying an RS256 token as HS256 using the public key as the secret.
Secrets in the payload
Never put passwords, API keys or personal data you would not show the user into a JWT payload; it is readable by anyone who holds the token.
Weak HMAC secret
HS256 tokens signed with short or guessable secrets can be brute-forced offline. Use a random secret of at least 256 bits, or an asymmetric algorithm such as RS256 or ES256.
openssl rand -base64 32Examples and command-line equivalents
Decode a JWT payload on the command line
JWTs use Base64URL without padding, so plain base64 -d often fails. This Python one-liner handles both.
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p + "=" * (-len(p) % 4))), indent=2))' "$TOKEN"A decoded payload
{
"iss": "https://auth.example.com",
"sub": "user_1234",
"aud": "api.example.com",
"iat": 1761100000,
"exp": 1761103600
}Frequently asked questions
Does decoding a JWT verify it?
No. Decoding only reads the Base64URL-encoded parts. Verification checks the signature against the issuer's key and is done by your server or an auth library.
Is it safe to paste a JWT into an online decoder?
Only if decoding happens locally, as it does here. A live access token grants whatever access it carries until it expires, so avoid pasting valid production tokens into tools that send them to a server.
Why is my token expired when I just got it?
Check the server and client clocks: exp is compared against the current time, and a clock that is minutes off can make fresh tokens look expired. Most libraries allow a small leeway for skew.
What is the difference between HS256 and RS256?
HS256 uses one shared secret to sign and verify, so every verifier can also mint tokens. RS256 signs with a private key and verifies with the public key, so services can verify tokens without being able to create them.