JWT Decoder
Decoded in your browser. Nothing is sent anywhere. A token is a live credential.
- HS256
- Algorithm
- 4
- Claims
- Expired
- Status
Expired 1041 days ago
The exp claim is 2023-11-14 23:13:20 UTC. This is what the token says, not what any server has checked.
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "Ada Lovelace",
"iat": 1700000000,
"exp": 1700003600
}- sub
- 1234567890Subject: who the token is about, usually a user id
- name
- Ada Lovelace
- iat
- 1700000000: 2023-11-14 22:13:20 UTCIssued at: when the token was created
- exp
- 1700003600: 2023-11-14 23:13:20 UTCExpiry: the instant after which the token must be rejected
3mJq0oVkOZ1sYyF7Zx6nE4oV0sQK9m7Wd0hQm1gqLpMDecoding is not verifying
The payload is Base64url, not encryption. Anyone holding the token can read it. Only the signature proves the token is genuine, and checking it needs the secret or public key, which belongs on your server and must never be pasted into a web page.
The decoder opens a JSON Web Token so you can see what is in it: the header, the payload, every claim with its meaning, and whether the expiry has passed. It runs entirely in your browser, which matters more here than anywhere else on this site. A JWT is a live credential.
How it works
A JWT is three Base64url-encoded parts separated by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. The first two parts are encoded, not encrypted. Anyone holding the token can read them.
- Registered claims are labelled with what they mean: iss the issuer, sub the subject, aud the audience, exp the expiry, nbf not-before, iat issued-at, jti the unique id.
- Timestamps are shown both as the raw seconds since 1970 and as a readable UTC date, because a bare ten-digit number tells you nothing.
- The expiry is compared against your clock and reported as expired or still valid, with the gap in plain language.
- The signature is displayed but never checked. Verifying it requires the secret or public key.
Decoding is not verification. A token whose claims look correct may be forged; only the signature establishes that it came from who it says. That check belongs on a server holding the key, which is precisely why the key must never be pasted into a web page.
Examples
A standard token
JWT
A three-part HS256 token
Result
Algorithm HS256, 4 claims, expiry checked
The header names the algorithm, the payload carries the claims, and the expiry is compared against your clock.
An expired token
exp
1700003600
Result
Expired, with the UTC date and how long ago
exp is seconds since 1970, not milliseconds, a common off-by-1000 error that makes a token appear to expire in the year 55000.
A token with the wrong number of parts
JWT
Two dot-separated segments
Result
Reported as not a JWT
Even an unsigned token has three parts, ending with a dot and an empty signature. Two parts usually means the token was truncated in transit.
Frequently asked questions
Does this verify the token's signature?
No. Verification needs the signing secret or public key, and pasting either into a web page would be a serious mistake. It is the thing that lets anyone mint valid tokens. Decoding shows you what a token claims; only your server can establish whether those claims are genuine.
Is it safe to paste a real token here?
The decoding happens entirely in your browser and the token is never transmitted. That said, a live JWT is a working credential. Treat pasting one anywhere with the same care as a password, and prefer an expired or test token when you only need to inspect the structure.
Why can anyone read my token's contents?
Because JWT payloads are encoded, not encrypted. Base64url is a transport encoding with no key. Never put anything confidential in a JWT payload: if you need the contents hidden, you need JWE, which is a different specification.
The token looks valid but my API rejects it, why?
Most often clock skew or the wrong key. A token issued by a server whose clock is a minute ahead fails an nbf check on a server whose clock is behind. After that, look at the aud and iss claims. An API will reject a perfectly valid token issued for a different audience.
What does the alg header of "none" mean?
It means the token is unsigned, and it should make you suspicious. Accepting alg: none was a widespread vulnerability, because an attacker could strip the signature and change the payload freely. Any correct implementation now rejects it unless unsigned tokens are explicitly expected.