What Is a JWT, and How Do You Decode One?
A JSON Web Token is a compact, signed way of carrying claims between systems - typically who a user is and what they are allowed to do. The JWT Decoder shows you what one contains.
Three parts, separated by dots
A JWT is three Base64-encoded segments joined by full stops.
The header says which algorithm signed it and that the type is JWT. The payload holds the claims - a subject, an issuer, an expiry, and whatever else the application put there. The signature is a cryptographic hash of the first two parts, computed with a secret or a private key.
Both the header and the payload are only Base64-encoded, which means they are not encrypted and not private. Anyone holding the token can read them with no key at all - which is exactly what the decoder is doing.
Decoding is not verifying
This is the distinction that matters most, and conflating the two is how real security holes get built.
Decoding reads the payload. Anybody can do it. It tells you what the token claims.
Verifying recomputes the signature with the secret and checks it matches - which proves the token was issued by someone holding that secret and has not been altered since.
A decoder deliberately does not verify, because it has no access to your secret. So never trust a decoded payload in application code. A tampered token decodes perfectly and says whatever the attacker typed. The library on your server has to verify, and it has to be told which algorithm to expect.
That last point is not theoretical: the classic JWT attack is changing the header's algorithm to "none" and stripping the signature, which older libraries accepted. Pinning the expected algorithm is the fix.
What belongs in a payload, and what does not
Because the payload is readable by anyone who has the token: no passwords, no personal data you would not publish, no internal secrets. A user id is fine. An email address is a judgement call. A national insurance number is not.
The standard claims are worth knowing: sub for the subject, iss for the issuer, aud for the intended audience, exp for the expiry time and iat for when it was issued. The two time fields are Unix timestamps, which is why a decoded token shows a long number rather than a date.
Keep expiry times short. A JWT cannot be revoked once issued - that is its main weakness, since the server holds no session to delete - so a leaked token is valid until it expires. Short-lived access tokens with a separate refresh mechanism is the usual answer.
Common questions
Is a JWT encrypted?
No. Signed, which proves origin and integrity, not secrecy. There is a separate encrypted standard, JWE, which is far less common.
Can I decode one without the secret?
Yes, trivially. That is the point of the decoder, and the reason not to put secrets in one.
Why is my token enormous?
Too many claims. Tokens travel on every request, so a bloated payload costs real bandwidth.
What if I only need a hash rather than a token?
Different job - the Hash Generator covers that.
Got a token to look inside?