JWT Decoder — decode JSON Web Token online
Decode the header, payload, claims and expiry of a JSON Web Token. The token is parsed in your browser and never transmitted — safe for real tokens.
About the JWT decoder tool
A JSON Web Token is three Base64url-encoded sections joined by dots. The header names the signing algorithm, the payload carries the claims — who the user is, what they may do, when the token expires — and the signature proves the first two were issued by someone holding the key and have not been altered since. Decoding the first two sections requires no key at all, which is what makes reading a token so easy.
That last point is worth sitting with, because it is where the most dangerous misconception about JWTs lives. The payload is encoded, not encrypted. Anyone who obtains a token can read every claim inside it instantly. Putting anything confidential in there — an internal user note, a personal identifier you would not publish, an email address you promised not to expose — means publishing it to anyone the token passes through.
What the signature protects is integrity, not secrecy. It guarantees that the claims were issued by the holder of the signing key and have not been edited, so a user cannot change their own role from user to admin and have the server believe it. Verifying that requires the secret or public key, which is why verification belongs on your server and never in a tool like this one.
In practice the reason to decode a token is debugging an authorisation failure, and the answer is usually in two claims. The exp claim is an expiry timestamp, and an expired token is by far the most common cause of a sudden 401 — often because the clock on one machine drifted rather than because real time passed. After that, check that the roles or scopes in the payload are actually the ones your endpoint requires.
How it works
Paste the token
Drop in the full three-part string. It is parsed on your own device and never transmitted anywhere.
Read the header and payload
The algorithm, every claim, and the issued-at and expiry times are shown as readable JSON with the dates resolved.
Check what you came for
Expiry is flagged when the token has lapsed, which is the usual explanation for an unexpected authorisation failure.
Frequently asked questions
- Is a JWT encrypted?
- No. The header and payload are Base64url-encoded, which is reversible by anyone with no key required. Signing proves the token was issued legitimately and has not been tampered with; it does nothing to hide the contents. Treat everything in the payload as public information, because to anyone holding the token it is.
- Does this tool verify the signature?
- No, deliberately. Verification requires the secret or public key, and asking you to paste a signing key into a web page would be far more dangerous than any convenience it offered — that key can mint valid tokens for your entire system. The signature is displayed so you can see it exists. Verification belongs in your backend.
- What do the standard claims mean?
- The common registered claims are iss (who issued it), sub (the subject, usually a user id), aud (the intended recipient), exp (expiry time), nbf (not valid before), iat (issued at) and jti (a unique token id). Times are Unix timestamps in seconds. Everything else in the payload is custom to the system that issued it.
- Why is my token being rejected as expired when it looks current?
- Usually clock skew. The exp claim is compared against the server's clock, so if the issuing machine and the validating machine disagree by even a minute, a token can be rejected before its stated expiry or accepted after it. Check that both systems synchronise time, and remember exp is in seconds while JavaScript timestamps are in milliseconds.
- Can I safely paste a real production token here?
- Yes. Decoding runs entirely in your browser tab — nothing is transmitted, stored or logged, and you can go offline and it still works. That is the reason to prefer a browser-side decoder: a live JWT is a working credential, and pasting one into a site that sends it to a server hands over a valid session.
- What does the alg field tell me?
- Which algorithm signed the token. HS256 uses a shared secret, so the same key signs and verifies. RS256 and ES256 use a private key to sign and a public key to verify, which is what you want when several services validate tokens issued by one authority. A token whose alg is set to none is unsigned and should always be rejected.
- Can I edit a token and use it?
- You can change the payload, but the signature will no longer match and any correctly implemented server will reject it. That is the entire purpose of signing. Editing claims is useful for understanding how your validation behaves, not for gaining access — a system that accepts a modified token has a serious bug in its verification.