JWT Decoder (Header, Payload, Expiry)
Paste a JSON Web Token and read its header and claims, with expiry and issue times as human dates, decoded on your device, not on a server.
| Claim | Local time | Means |
|---|
Decoding is not verification. Anyone can read a JWT, this shows what it says, not whether its signature is genuine. Only the issuing server can check that.
Free forever, no sign-up and no limits, and this tool installs on its own so you can keep it on your home screen.
Paste a JSON Web Token and read what is inside: the header, every claim pretty-printed, and the times (expiry, issue, not-before) turned into real dates with 'expires in 2 hours' phrasing that stays current while the tab is open. Paste a bare token, a whole Authorization header or a URL carrying one, and the token is found and opened without you having to trim it first.
How to use it
- Paste anything holding the tokenA bare token, 'Bearer eyJ…', a full Authorization header or a URL with the token in a query parameter. The JWT is extracted automatically.
- Read the verdictValid, expired or not yet valid is the headline, with the exact moment, the distance from now, and a warning if the header declares a suspicious signing algorithm.
- Inspect the claimsHeader and payload as formatted JSON, time claims as a readable table, and the payload one tap from your clipboard.
What is actually inside a JWT
Three Base64url segments joined by dots. The header names the signing algorithm. The payload carries the claims, who the token is about (sub), who issued it (iss), who may accept it (aud), and the timestamps that bound its life. The third segment is the signature over the first two. Nothing is encrypted; the encoding exists to survive URLs and headers, not to conceal.
That transparency is why decoding is a daily debugging move: the answer to "why did the API reject this request" is very often sitting in the payload, an expired exp, a wrong audience, a missing scope, visible in the time it takes to paste.
Expiry first, because expiry is the question
In practice, people decode tokens to answer one question: is this thing still valid? So that answer is the big block at the top, valid or expired, the exact moment, and the distance from now in human terms. The full claims table is there for the deeper dig, but the 401-at-2am case is settled in one glance.
The relative times matter more than they look. Clock skew between servers routinely produces tokens that are "not valid yet" for a few seconds, an nbf a moment in the future is instantly visible when the table says "valid from in 30 seconds". And the phrasing keeps itself honest: leave the tab open and "expires in 12 minutes" ticks down each minute until it flips to expired, so the verdict you glance back at is never stale.
Decoded is not verified
The permanent warning under this tool is the most important sentence on the page. Anyone can mint a token claiming to be anyone, decoding it faithfully shows those claims. Only a signature check against the issuer's key separates a genuine token from a costume, and that check belongs to the server. Treat this page as reading glasses, never as a passport control.
Questions people ask
Will it open a session token that is not a JWT?
No, and it says so rather than guessing. An opaque session token is a random string with no structure inside it, so there is nothing to lay out. If your value has three dot-separated parts and begins with eyJ, it is a JWT and this page will open it. A token that has been through a clipboard is always worth rotating afterwards.
Why can anyone decode a JWT, is that not broken?
By design, a JWT is readable by anyone holding it: the header and payload are just Base64url-encoded JSON. The signature does not hide the contents, it lets the issuing server detect tampering. Signed, not secret. The rule that follows: never put anything in a JWT payload you would not show the user carrying it.
Why will my token not decode?
The usual causes, in order: the token was truncated in copying (they are long, and logs cut them), an extra character came along, or it is not a JWT at all, opaque session tokens and API keys do not have the three dot-separated parts. The error message says which of these it saw.
What are exp, iat and nbf?
Unix timestamps controlling the token's lifetime: exp is when it stops being valid, iat when it was issued, nbf a time before which it must be rejected. This tool converts each to your local time and to relative terms, because 1787340000 tells a human nothing.
Can this tell me whether the token is genuine?
No, and be suspicious of any tool that claims to. Verifying the signature requires the issuer's secret or public key; without it, decoding shows what the token asserts, not whether the assertion is authentic. The warning under the tool is permanent for that reason.
My token says expired but the app still works, why?
Sessions usually pair a short-lived access token with a longer-lived refresh token; the app silently exchanges an expired access token for a fresh one. What you decoded is the access token's own lifetime (commonly minutes to an hour) not the length of your login.
Can I paste a whole Authorization header or a URL?
Yes. The tool looks for the token inside whatever you paste: 'Bearer eyJ…', a full 'Authorization: Bearer …' header copied from developer tools or a curl command, or a URL carrying the token in a query parameter or fragment. A JWT's first two parts always begin with the same three characters, which makes it findable in surrounding text.
What does the algorithm warning mean?
The token's header names the algorithm that supposedly signed it. Almost every real issuer uses one of the HS, RS or ES families (HS256, RS256 and ES256 are the common ones). A header saying 'none' means the token is unsigned and anyone could have written it; an algorithm outside the expected families is either exotic or an attack probe. The warning appears in both cases, quietly, because the token may still be one you legitimately need to read.