JWT → readable
Paste a token and read what is actually inside it. Every registered claim is explained, timestamps are converted to real dates with the time remaining, and the algorithm is checked against the choices known to cause trouble. Nothing is uploaded.
- Reads
- JWS compact · Bearer headers
- Explains
- iss · sub · aud · exp · nbf · iat
- Checks
- Expiry · not-before · algorithm
Your token
What it contains
waiting for a token
waiting for a token
waiting for a token
waiting for a token
What a JWT actually is
Three parts, two of them readable
A JWT is header.payload.signature. The first two are base64url-encoded
JSON — that is encoding, not encryption. Anyone holding the token can read every
claim in it, including in a browser console.
So never put a secret in one
No passwords, card numbers, national ids or internal notes. Treat the payload as public text that happens to be tamper-evident. The signature proves nobody changed it; it does nothing to hide it.
The signature is the only guarantee
It proves the header and payload have not been altered since the issuer signed them.
It says nothing about whether the token is still valid — that is what
exp is for, and your server must check it.
Why we do not verify here
Verifying needs your signing secret or private key. Any site asking you to paste that into a web form is asking for the keys to your authentication. Verification belongs on your server, in a maintained library.
Pin the algorithm server-side
The alg header is chosen by whoever made the token, so it cannot be
trusted. Configure the expected algorithm in your verifier instead. Libraries that
obeyed the token's own header are the origin of the classic alg:none
and RS256-to-HS256 confusion attacks.
Logging out is the hard part
A signed token stays valid until it expires; there is no server-side session to delete. That is why access tokens are usually short-lived, with a revocable refresh token behind them.
The registered claims
| Claim | Name | What it is for |
|---|---|---|
iss | Issuer | Who created and signed the token. Your verifier should check this matches the issuer you expect. |
sub | Subject | Who the token is about, usually a stable user id. Should be unique and never reused. |
aud | Audience | Who the token is for. An API that skips this check will happily accept a valid token meant for a different service. |
exp | Expiry | Unix seconds after which the token must be rejected. Required in practice, even though the spec calls it optional. |
nbf | Not before | Unix seconds before which the token is not yet valid. Useful for tokens issued ahead of time. |
iat | Issued at | When the token was created. Handy for rejecting tokens older than a policy allows. |
jti | JWT ID | A unique id for this token, so a replay can be detected and a single token revoked. |
Common questions
Is a JWT encrypted?
No. It is encoded and signed. Assume everyone can read the payload.
Is my token sent anywhere?
No. Decoding happens in your browser; the token never leaves the page.
Can I edit a token here?
You could change the payload, but without the signing key the signature will no longer match and any correct verifier will reject it.
Why does my token look expired?
The exp claim is in seconds, not milliseconds. A value ending in three extra zeros is the usual cause.