JWT Decoder
Paste a token to see its decoded header and payload, with exp, iat and nbf claims rendered as readable dates. Decoding happens in your browser; the token is never sent anywhere. The signature is not verified, so a clean decode does not prove a token is valid; the tool also warns when a header declares "alg": "none".
About this tool
A JSON Web Token is three Base64url segments joined by dots: header, payload, signature. This tool splits them and shows the decoded header and payload, with exp, iat and nbf claims rendered as readable dates and expired tokens flagged. It does not verify the signature — a clean decode means the token is well-formed, not that it is valid — and it warns when the header declares alg "none". Decoding happens locally, which makes it a safer way to inspect a token than pasting it into a site that could log it.
When to use it
Questions
Does decoding verify the signature?
No. Verification needs the secret or public key that signed the token and happens on the server that issued it. Anyone can change a token's header and payload and re-encode them, which is exactly why decoded claims prove nothing on their own.
Is it safe to paste a token here?
Decoding runs locally in your browser and the token is not transmitted. Treat any long-lived token as sensitive regardless: if it may have leaked, revoke it instead of hoping nobody recorded it.
Why does my token fail to decode?
A JWT is exactly three dot-separated parts, each Base64url-encoded JSON. Extra dots, a missing signature segment, or a segment that is not valid JSON all fail with a message naming the problem. Truncated copies are the usual culprit — paste the whole token, including the final segment.
What is the difference between a JWT's header, payload and signature?
The header names the signing algorithm and token type, the payload carries the claims, and the signature is what ties both to the issuer's key. The first two are plain Base64url — anyone can read them, which is why the decode is instant. The signature exists so the server holding the key can prove neither part was altered; decoding shows you the contents, never their authenticity.
What do the exp, iat and nbf claims mean?
All three are timestamps in seconds since the Unix epoch. iat is when the token was issued, nbf is the earliest time it counts as valid, and exp is when it stops being valid — after that date a server should reject it, and this tool flags the token as expired. If a token you were handed died sooner than expected, exp is the claim to read first.
Why does decoding my token show garbage or an error?
Two common causes. If the string is valid Base64 but the payload is unreadable, it is probably an encrypted token — a JWE — whose payload is ciphertext, not JSON; JWT only guarantees readable claims for a plain JWS token. If it does not decode at all, check for a truncated copy, a missing third segment, or a token from a non-JWT scheme that merely looks similar.