JSON Web Tokens are everywhere in modern authentication: your app logs in, receives a long encoded string, and sends it back with every request. When something breaks — a 401 error, a permission that should work but does not — the first debugging step is decoding the token to see what is actually inside it. The catch: a JWT is a credential, so where you decode it matters. This guide shows how to decode a JWT safely and explains what each part means.
Decode a JWT in your browser
- Open the free JWT decoder.
- Paste the full token into the input — it should look like three base64 strings separated by dots (
xxxxx.yyyyy.zzzzz). - The header and payload are decoded instantly and shown as readable JSON.
- Check the claims table below to interpret what you see.
The decoder runs entirely in your browser: your token is never uploaded, logged, or transmitted anywhere. That is the whole point — pasting a live access token into a random upload-based decoder is equivalent to handing your password to a stranger.
The three parts of a JWT
A JWT has three dot-separated segments. The header is a small JSON object stating the token type and the signing algorithm, typically {"alg":"HS256","typ":"JWT"}. The payload carries the claims — statements about the user and the token itself, such as who it was issued to and when it expires. The signature is created by signing the header and payload with a secret; the server uses it to verify the token has not been tampered with. Decoding reads the first two parts; only the issuer can validate the third.
Common claims, explained
| Claim | Name | What it means |
|---|---|---|
iss | Issuer | Who created the token, e.g. your auth provider |
sub | Subject | Who the token is about — usually a user ID |
aud | Audience | Who the token is intended for, e.g. an API identifier |
exp | Expiration | Unix timestamp after which the token is invalid |
iat | Issued at | Unix timestamp of when the token was created |
nbf | Not before | Unix timestamp before which the token is not valid |
The time-based claims (exp, iat, nbf) are Unix timestamps — seconds since January 1, 1970. If you need to convert one to a readable date, a timestamp converter does it instantly. Remember that decoding is not verification: anyone can decode a JWT, because the payload is only base64-encoded, not encrypted.
Why client-side decoding matters
Most JWT decoder sites send your pasted token to their server to process it. That server now holds a credential that may grant access to your user's account, your staging environment, or production data — and you have no visibility into how long it is stored or who can see it. A decoder that runs 100 percent in the browser eliminates that risk entirely: the token bytes never leave your machine. For the same reason, never paste a JWT into chat logs, screenshots, or issue trackers either.
Frequently asked questions
Is it safe to paste a JWT into an online decoder?
Only if the decoder runs entirely in your browser. A JWT grants access to whatever it authorizes, so pasting it into an upload-based site hands your credentials to a stranger. Client-side decoding keeps the token on your device.
What do the three parts of a JWT mean?
The header states the token type and signing algorithm, the payload carries the claims (who the token is for, when it expires), and the signature lets the issuer verify the token has not been tampered with.
Why does my JWT say it is expired?
The exp claim holds a Unix timestamp after which the token is no longer valid. Compare it against the current time — most access tokens expire after minutes or hours by design, and you need to request a fresh one.