JWT Decoder
Decode a JWT to read its header, payload and claims. Shows expiry, flags unsigned tokens, and never leaves your browser. No signature verification.
Header
Payload
This decodes the token; it does not verify the signature. Anyone can read a JWT's contents — that is by design — so never treat a decoded payload as proof of anything until your server has checked the signature against its key.
Related tools
All Developer tools →This tool runs entirely in your browser. Nothing you enter is sent to our servers, so there is nothing for us to store or see.
About the JWT Decoder
Paste a JSON Web Token to see its header and payload decoded, with every registered claim explained and the timestamps rendered as readable dates. It tells you immediately whether the token has expired and how long is left, which is the answer you usually came for.
This tool decodes; it does not verify. That is a deliberate limit, not a missing feature. Verifying a signature requires the secret or public key that produced it, and a web page that asks you to paste your signing secret into a form is teaching a habit that will eventually cost someone their production keys. Verification belongs on your server, with your key, never in a browser tab.
It is worth being clear about what a JWT actually protects. The payload is base64url, not encryption — anyone holding the token can read every claim in it, and that is by design. The signature proves the contents have not been altered; it does not hide them. So never put a password, an API key or anything else confidential in a JWT payload.
The decoder flags the things worth noticing: an alg of none, which means the token is unsigned and forgeable by anyone; a missing exp claim, which means it never expires on its own; and a lifetime over a year, which cannot be revoked without rotating the key. Everything runs in your browser, so a real production token pasted here is never transmitted.
How to use the JWT Decoder
-
Paste your token
The whole JWT, or the Authorization header value — a leading "Bearer " is stripped automatically.
-
Read the header and payload
Both are decoded and pretty-printed as JSON. The line beneath the input tells you whether the token is currently valid and for how much longer.
-
Check the claims
Every registered claim is explained in plain language, and time claims such as exp, nbf and iat show the raw number alongside the date it represents.
-
Read the warnings
Unsigned tokens, missing expiry and unusually long lifetimes are called out. Anything flagged in red is worth investigating before the token is trusted.
Frequently asked questions
Does this verify the signature?
No, deliberately. Verification needs the secret or public key that signed the token, and pasting a production signing secret into a web page is a habit worth never forming. Decode here to see what is inside; verify on your server, where the key belongs.
Is my token sent to a server?
No. Decoding happens entirely in your browser using its built-in base64 support, and nothing is transmitted or stored. That is what makes it safe to paste a real token, which is more than can be said for tools that decode server-side.
Is the payload of a JWT encrypted?
No. It is base64url-encoded, which is an encoding and not encryption — anyone holding the token can read every claim in it. The signature proves the contents were not tampered with; it does not conceal them. Never put passwords, API keys or personal data you would not want read into a JWT payload.
What does "alg: none" mean and why is it flagged?
It means the token carries no signature at all. The specification allows it, but a system that accepts such tokens is trusting content that anybody can forge — simply write whatever claims you like and set the algorithm to none. It has been the basis of real authentication bypasses, so any library you use should reject it outright.
My token looks valid but the server rejects it — why?
The most common causes are clock skew between the issuer and verifier, an aud or iss claim that does not match what the server expects, a key that has been rotated since the token was issued, or the token being signed with a different algorithm than the server accepts. The expiry shown here is checked against your own device clock.
What is the difference between exp, nbf and iat?
iat is when the token was issued, exp is when it stops being valid, and nbf is a time before which it should not be accepted — useful for tokens minted in advance. All three are Unix timestamps in seconds, shown here as both the raw number and a readable date.