How to use
- Paste the complete token: three Base64URL parts separated by dots.
- Read the decoded header and payload. The exp, iat and nbf claims are shown as dates, with a warning when the token is expired or not yet valid.
- To verify the signature, enter the shared secret for HS256, HS384 or HS512, or paste the PEM public key for RS, PS or ES algorithms.
- Check that the issuer, audience and subject claims match what your application expects.
How a JWT is built
A JSON Web Token (RFC 7519) has three parts separated by dots: header.payload.signature. The header and payload are JSON objects encoded as Base64URL without padding, which is why tokens almost always begin with eyJ, the encoded form of an opening {". The signature is calculated over the first two parts exactly as they appear in the token.
- Header: the signing algorithm in
alg, usually"typ": "JWT", and often akidthat names the key. - Payload: the claims, such as who the user is, who issued the token and when it expires.
- Signature: an HMAC, RSA or ECDSA signature proving that header and payload have not been changed.
A token with five parts is an encrypted JWE; its content cannot be read without the decryption key.
Registered claims
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token |
sub | Subject | Whom the token is about, usually a user ID |
aud | Audience | The service the token is meant for |
exp | Expiration time | After this moment the token must be rejected |
nbf | Not before | Before this moment the token must be rejected |
iat | Issued at | When the token was created |
jti | JWT ID | Unique identifier, used to detect replays |
Times are NumericDate values: seconds since 1 January 1970 UTC, not milliseconds. The decoder shows them as readable dates and compares them with your device clock.
Decoding is not verifying
Anyone can decode a JWT, because the payload is only encoded, not encrypted; never put passwords or other secrets in it. Trust comes only from checking the signature with the right key, and a server that accepts tokens should also:
- allow only the algorithm it expects and reject
"alg": "none", which marks an unsigned token; - never let the token header pick between HMAC and RSA, or an attacker can sign a forged token with your public key used as an HMAC secret;
- check
exp,nbf,issandaudon every request.
The optional verification on this page uses the Web Crypto API built into your browser. Decoding and verification happen on your device and nothing is uploaded. As a general rule, never paste production signing keys or live tokens into websites you do not trust.
Frequently asked questions
Is it safe to paste a JWT into this decoder?
The token is decoded and verified by JavaScript in your browser and is never sent to a server. Keep in mind that a token that has not expired works like a password for whoever holds it, so prefer test or expired tokens when you share screenshots or logs.
Can I decode a JWT without the secret key?
Yes. The header and payload are plain Base64URL-encoded JSON, so they can be read without any key. The secret or public key is only needed to verify the signature.
Why does the decoder say my token has expired?
exp claim lies before the current time on your device. If the token should still be valid, check your system clock and the token lifetime configured by the issuer.Which signature algorithms can be verified?
HS256, HS384 and HS512 with a shared secret, and RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512 with a public key in PEM format.
What does "alg": "none" mean?
It marks an unsecured JWT with an empty signature, defined in RFC 7518. Anyone can create or change such a token, so a server that expects signed tokens must always reject it.