Free tool
JWT decoder
Paste a JSON Web Token to read its header and claims, see when it expires, and check an HMAC signature. Decoding happens in your browser; nothing is sent.
Token
Whitespace, line breaks and a Bearer prefix are ignored.
Paste a token above, or load the example to see how it works.
Anatomy
Three parts and two dots
- Header
- How the token is signed: alg such as HS256 or RS256, a typ, and often a kid naming the key.
- Payload
- The claims: who the token is about, who issued it, who it's for, when it expires, plus whatever the app adds.
- Signature
- A MAC or digital signature over the first two parts. Change one character of them and it stops matching.
- Base64url
- Each part is base64url-encoded JSON or bytes, joined by dots. Encoding isn't encryption: anyone can reverse it.
Claims
The registered claims
- issIssuer
- Who created the token, often a URL. Check it matches the issuer you trust.
- subSubject
- Who the token is about, usually a user ID.
- audAudience
- Which service the token is for. A server should reject tokens meant for someone else.
- expExpiration
- After this time, in seconds since 1970, the token must be refused.
- nbfNot before
- Before this time the token must be refused.
- iatIssued at
- When the token was created. Useful for spotting very old tokens.
- jtiJWT ID
- A unique ID, so a server can block a token from being replayed.
The times are plain numbers, seconds since 1 January 1970 UTC. A value with 13 digits is almost always milliseconds by mistake, and the decoder flags it, because most libraries would read it as a date thousands of years from now.
Security
Decoding isn't verifying
Anyone can write a JWT with any claims they like. What makes one trustworthy is the signature, checked by the server with a key it already holds, never with a key or an algorithm the token asks for. The classic mistakes all break that rule:
- alg: none tokens carry no signature at all. Some libraries once accepted them when asked.
- Algorithm confusion: a server expecting RS256 is handed an HS256 token signed with its own public key as the HMAC secret, and verifies it if the code trusts the header's alg.
- Header-supplied keys: jwk, jku or x5u pointing at a key the attacker controls.
- Weak HMAC secrets. HS256 secrets can be guessed offline from a single token, so use at least 32 random bytes.
This decoder flags each of these it can see in a token. For a strong HMAC secret, the secret key generator makes one in your browser.
Privacy
Why a decoder should run locally
A token you're debugging is often a real one, and a real token is a credential until it expires: whoever holds it is signed in as that user. Pasting it into a site that sends it to a server, or logs it in analytics, hands that session to someone else. This page decodes with JavaScript in your tab and verifies with your browser's Web Crypto. There is no request, no storage and no history, and the code is open source under the MIT license.
When a teammate needs a token or a signing secret, don't paste it into chat where it stays in the history. Send it with EnvShare: it's encrypted in your browser and deleted after the number of reads you choose.
FAQ
Questions
Is it safe to paste a JWT here?
The token is decoded by JavaScript in your tab and never sent to our server or anyone else's; the page makes no network request when you paste. Still, a live token is a credential: whoever holds it can act as you until it expires. Prefer expired or test tokens on any website, and you can confirm in your browser's network tab that nothing leaves.
Can a JWT be decoded without the secret?
Yes. The header and payload are only base64url-encoded, not encrypted, so anyone with the token can read them. The secret or key is needed to verify the signature, or to create a new token, not to read one.
Why does it say the signature doesn't match?
Usually the secret is wrong or in the wrong format: many apps store it base64-encoded, so try the Base64 option. Otherwise the token was changed after signing, or it was signed with a different algorithm or key than you expect.
What do exp, iat and nbf mean?
They're times in seconds since 1 January 1970 (UTC). exp is when the token stops being valid, iat when it was issued, and nbf the moment before which it must not be accepted. Servers often allow a minute or two of leeway for clock differences.
What's the difference between HS256 and RS256?
HS256 uses one shared secret to sign and to verify, so every service that checks the token could also mint one. RS256 and ES256 sign with a private key and verify with a public key, so verifiers can't create tokens. This tool verifies HS256, HS384 and HS512.
Is a JWT encrypted?
A normal JWT is signed, not encrypted: tampering is detectable, but the contents are readable. Encrypted tokens (JWE) have five parts instead of three; the decoder shows their header and tells you the payload needs the key.
Why is alg none dangerous?
It means the token has no signature, so anyone can write any claims they like. Some older libraries accepted such tokens when the header asked for it. A server should fix the algorithms it accepts and reject everything else, including none.