JWT Decoder
Decode a JSON Web Token online: read its header and payload, every claim explained, the exp and iat times as dates, and whether it has expired. In your browser.
Header
Payload
The payload isn't JSON, so it is shown as text.
Claims
| Claim | Value |
|---|
Signature
JWT Decoder: A Quick Guide
Paste a JSON Web Token to read what is inside it: the header, the payload with every claim explained, the dates in plain words, and whether the token has expired. The token is decoded in your browser and never sent anywhere, so the page works the same offline.
What is a JWT?
A JSON Web Token (JWT, said "jot") is a small, signed piece of JSON that a server hands out after a login, and that the client then sends with each request, usually as Authorization: Bearer <token>. It has three parts separated by dots:
- Header: the token type and the signing algorithm, such as
{"alg":"HS256","typ":"JWT"}. - Payload: the claims, statements about the user and the token: who it is for, who issued it, when it expires.
- Signature: made from the first two parts with the issuer's secret or private key, so that nobody can change them unnoticed.
The header and the payload are only encoded in Base64url, not encrypted. Anyone who has a token can read them, which is what this tool does. That is why a JWT should never carry a password or other secrets.
How to use the JWT Decoder
- Paste the token into Encoded Token. A leading
Bearer, surrounding quotes and line breaks are ignored, so you can paste it straight from a header or a JSON file. - Read the status under the field: expired, not valid yet, not expired, or no expiry at all.
- Look at the Header and the Payload, indented for reading, and copy either with its copy button.
- Check the Claims table for what each claim means, with every time shown as a date.
Press Example to see a sample token decoded.
The standard claims
Any claim can appear in a payload, but seven are defined by the JWT standard, RFC 7519:
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token |
sub | Subject | Whom the token is about, usually a user id |
aud | Audience | Who the token is meant for |
exp | Expiration time | The token must not be accepted after this time |
nbf | Not before | The token must not be accepted before this time |
iat | Issued at | When the token was created |
jti | JWT ID | A unique id for the token, against replays |
Tokens from OpenID Connect sign-ins add claims about the user, such as name, email and auth_time, and OAuth access tokens often carry scope. The Claims table explains these too.
Reading the times
The times in a JWT are Unix times: whole seconds since 1 January 1970, UTC. "exp": 1893456000 is 1 January 2030, 00:00:00 UTC. The decoder shows each time as a date in UTC and how long ago or from now it is. A time with 13 digits is almost always in milliseconds by mistake, and the decoder points that out.
Decoding is not verifying
Decoding only reads the token. It doesn't prove that the token is genuine: that takes the signature, checked with the issuer's secret (for HS256 and the other HMAC algorithms) or its public key (for RS256, ES256 and the others). Your server must always verify a token before trusting it. A token whose header says "alg": "none" is unsigned, and anyone could have written it.
Frequently asked questions
Is it safe to paste a token here?
The token is decoded by this page in your browser, and nothing is sent or stored. Still, a token that hasn't expired works like a password until it does: keep live production tokens out of chats, tickets and screenshots.
Why does the token say it has expired?
Its exp time has passed by your device's clock. Access tokens usually last minutes to an hour, and the app is expected to get a new one with a refresh token. If a fresh token already shows as expired, check the clock of the server that issued it.
Can a JWT be encrypted?
Yes: an encrypted token, a JWE, has five parts instead of three, and only the recipient's key can open it. This decoder recognises one and says so, but it can't read its contents.
What is the difference between a JWT and a session cookie?
A session cookie holds an id that the server looks up in its own storage. A JWT carries the data itself, signed, so any server with the key can check it without a lookup. The price is that a JWT can't easily be revoked before it expires, which is why access tokens are kept short-lived.