JWT Decoder
Decode a JSON Web Token’s header and payload locally, with expiry dates translated into readable times.
Processed on your device — no upload
Decoded in your browser. A JWT is a live credential — pasting one into a site that uploads it hands over whatever it authorises.
Paste a token. Its header, payload and expiry are decoded here — in this page, never sent anywhere.
How to use it
- Paste the token.
- Read the header, the claims and the expiry.
- Nothing is sent anywhere while you do it.
How it works
A JWT is three URL-safe Base64 sections separated by dots: a header saying which algorithm signed it, a payload of claims, and a signature over the first two. The first two are encoded, not encrypted, so decoding is simply Base64 followed by a JSON parse.
Anyone holding the token can read the payload. That is a design property, not a flaw — but it means a JWT must never carry anything secret. Tokens containing internal identifiers, email addresses and role names are readable by every party they pass through, including the browser they are stored in.
Decoding is not verification. The signature is what proves the token was issued by who it claims and has not been altered, and checking it requires the secret or public key — which only the issuing server holds. Any decoder claiming to verify a token either has your key or is not really verifying.
The timestamp claims — iat, nbf, exp — are Unix seconds, translated here into readable UTC times, with the expiry marked against the current moment.
A worked example
Press Load a sample token. The header shows HS256 and JWT; the payload shows a subject, a name, a role and two timestamps.
The role: admin claim illustrates the point about secrecy. Everyone who handles this token can see it — including the browser it is stored in, any proxy it passes through, and any log that records the request. A JWT is a bearer credential: whoever has it can use it.
This is exactly why the decoder should be local. The usual debugging move is to paste a token into an online decoder while chasing an auth bug. That token is live, it authorises whatever the user could do, and it has just been sent to a third party. If you have ever done it — and most developers have — rotate the secret.
The expiry line is the fastest answer to “why is this request failing”. Anexp in the past shows as expired, and that is the end of the investigation. A common variant is a token that is valid but whose nbf is in the future, usually because two servers' clocks disagree.
To understand the encoding underneath, the Base64 tool decodes any single part by hand.
Questions
Is my token sent anywhere?
No. It is decoded in your browser. This is the whole reason to use a local decoder — a JWT is a live credential, and pasting one into a site that uploads it discloses it.
Does this verify the signature?
No. Verification needs the secret or public key, which only the issuing server has. Decoding shows you what the token says; it cannot show you whether to believe it.
Is the payload encrypted?
No, only encoded. Anyone with the token can read every claim, which is why a JWT must never contain anything secret.
I pasted a real token into an online decoder. What should I do?
Treat it as disclosed. Rotate the signing secret if you control the issuer, and invalidate the session. Most developers have done this at least once.
What do iat, nbf and exp mean?
Issued at, not valid before, and expires — all Unix timestamps in seconds. They are shown here as readable UTC times with the expiry checked against now.
Why does my token fail even though it has not expired?
Often the nbf claim is slightly in the future because two servers' clocks disagree. Check that line as well as the expiry.
What does the alg field mean?
The signing algorithm — HS256 for a shared secret, RS256 for a public key pair. A token with alg set to "none" is unsigned and should never be trusted.
Can I edit the payload and re-sign it?
Not here. Changing a claim invalidates the signature, and producing a valid one needs the key. That is precisely what the signature is for.