How it works
- Paste your JWT.
- Read the header and claims, and the expiry status.
- Optionally enter a secret or public key to verify the signature.
Why use it
- Readable dates for exp, iat and nbf.
- Verifies HMAC, RSA and ECDSA signatures.
- Shows algorithm warnings such as none.
- Your token never leaves the page.
Reading and checking JSON Web Tokens
What is inside a token
A JSON Web Token is three pieces of Base64 text joined by dots: a header, a payload and a signature. The header names the signing algorithm; the payload holds the claims, such as who the user is and when the token expires; the signature proves that whoever made the token knew the key. Paste a token and the first two pieces are decoded and shown as JSON, with the standard claims named in plain words:
| Claim | Meaning |
|---|---|
iss | Issuer: the service that made the token |
sub | Subject: usually the user's ID |
aud | Audience: the service the token is meant for |
exp | Expires: after this moment the token must be refused |
nbf | Not valid before this moment |
iat | Issued at: when the token was made |
Decoding is not verifying
Anyone can decode a JWT; the payload is not encrypted, only encoded. So never put secrets in a token, and never trust the claims of a token until its signature has been checked. To verify one here, paste the key:
- HS256, HS384, HS512 use one shared secret, the same on both sides. Tick the Base64 option if the secret is stored that way.
- RS, PS and ES algorithms use a key pair: the token is signed with a private key and checked with the public key, which you can paste as a PEM key, a certificate or a JWK.
A token signed with alg: none has no signature at all, and the decoder warns you: a server that accepts it would trust anyone who edits the payload. Libraries should always be told which algorithms to accept.
Keep production tokens private
A valid token is a key: whoever holds it can act as that user until it expires. That is why this decoder runs entirely in your browser, and why you should be careful with online tools that send the token to a server. Prefer test tokens when you can, and treat any real token you pasted somewhere public as leaked.
Making test tokens
The Encode tab signs tokens with your own header, payload and key, using any of the twelve algorithms. It can add the issued at time and an expiry a chosen number of minutes ahead. Useful for testing how an API handles expired tokens, wrong audiences or missing claims, without touching a real login.
If something goes wrong
- It says the token is not valid. A JWT must have exactly two dots. Check that nothing was cut off when copying; a leading
Beareris removed for you. - The signature does not verify. The key is wrong, the secret should be read as Base64, or the token was changed after signing.
- It says the token expired, but the server accepts it. The server may allow some clock leeway, or not check expiry at all, which is worth fixing.
Questions and answers
Is it safe to paste a real token?
Decoding happens locally and nothing is sent. Still, treat production tokens as secrets and prefer test tokens when you can.
Can it verify a signature?
Yes, with the shared secret for HS256 or the public key for RS256 and ES256.
Why does my token show as expired?
The exp claim is a Unix time. The tool compares it with the clock on your device.