JWT Decoder

What a JWT decoder shows you, and what it cannot

A JSON Web Token in its compact form is three chunks of base64url joined by dots: header.payload.signature. The first chunk says which algorithm signed the token and, usually, which key was used. The second is the set of claims: who the token is about, who issued it, who it is for, and when it stops being good. The third is the signature over the first two. This page reverses the base64url on the first two chunks, pretty-prints the JSON, and turns exp, iat and nbf into dates you can read.

The important word is decode. This page does not verify the signature and cannot tell you whether a token is genuine. Verification needs the shared secret for an HMAC algorithm such as HS256, or the issuer’s public key for RS256, ES256 or EdDSA, and a page that asked you for either would be asking for the wrong thing. What you get here is what the issuer claims, which is exactly what you need when you are reading a token, and nothing like enough to decide whether to trust it.

The quick version people write by hand, JSON.parse(atob(token.split('.')[1])), fails in two ways that are easy to miss. Base64url replaces + and / with - and _ and drops the = padding, so atob either throws or returns rubbish; and atob hands back one byte per character, so a name with an accent, an emoji or any Japanese or Korean text comes out mangled. This page fixes the alphabet, restores the padding, and decodes the bytes as UTF-8.

Which part of the token answers which question

• Header, for key and algorithm problems: alg tells you how it was signed and kid names the key. When verification fails on the server, a kidthat is missing from the issuer’s key set is the first thing to look for.
• Time claims, for “it worked five minutes ago”: the panel above converts exp, iat and nbf from Unix seconds into local dates, so you can see at a glance whether the token has run out or has not started yet.
• iss and aud, for 401 responses from the right-looking token: a token minted by your staging tenant will not pass an audience check in production, and the two look identical until you read these two claims.
• sub, for “which user is this?”: the subject is normally the stable user id. It is what you paste into a database query when a support ticket arrives with a token attached.
• Scopes, roles and custom claims, for 403 responses: if the request is authenticated but refused, the permission the API wanted is usually missing from the payload rather than wrong on the server.
• Signature, for almost nothing on its own: it is shown so you can confirm it exists and is not empty. An empty third segment means the token was issued with alg set to none, which no current library should accept.
• When you need verification, not decoding: use a library on the server. In JavaScript the jose package handles both verification and remote key sets; in Python it is PyJWT; in Go, golang-jwt.

How to debug a 401 with the token in front of you

1. Copy the token out of the Authorizationheader in your browser’s network panel, or out of the API client that made the call. Drop the leading Bearer and the space after it.
2. Paste it above. If the decode fails, the problem is the copy rather than the token: look for a line break in the middle or percent-encoding left over from a URL.
3. Read the status line. If it says expired, you are looking at a refresh problem, not an authentication problem, and the fix is in whatever is meant to renew the token.
4. Compare iss and aud with what the API expects. Mismatched environments are the most common cause of a 401 on a token that decodes perfectly.
5. Check alg and kidagainst the issuer’s published key set. A rotated key that your service has cached for too long produces a signature failure with no other symptom.
6. Only then look at the payload for the scope or role the endpoint requires. A missing permission normally produces a 403, so if you are getting a 401 the cause is above this step.

How to read the expiry without doing the arithmetic

1. Paste the token. The banner shows whether exp has passed and how long is left or how long ago it lapsed.
2. Read the time panel for the raw Unix seconds next to the local date. If a number looks a thousand times too large, the issuer put milliseconds in a field that RFC 7519 defines as seconds, which breaks every standard verifier.
3. Subtract iat from exp to get the lifetime. Fifteen minutes to an hour is typical for an access token; a token good for a year is a design decision worth questioning, because it cannot be withdrawn.
4. If there is no exp at all, the tool says so rather than guessing. A token with no expiry is valid until the signing key is rotated.
5. Remember that the verdict here uses your device clock. The server uses its own, which is why tokens sometimes fail a minute before or after you expect.

Getting the decoded claims into a ticket or a message

Select the payload block and copy it like any other text. It is formatted JSON, so it drops straight into a code fence in a pull request, an issue or a chat message. Before you send it anywhere, remember that the claims describe a real person: an email address, a user id, a tenant name and a role list are all common, and all of them are personal or commercially sensitive.

• Share the claims, not the token. Paste the decoded JSON with the values you are discussing and replace the rest with placeholders. The token itself is a live credential; the decoded shape usually is not.
• iPhone and iPad: press and hold on the block, drag the selection handles over the whole payload and tap Copy. Turning the phone to landscape stops the long lines wrapping into a maze.
• Android: press and hold, then use the selection handles. Gboard keeps a clipboard history, so clear the entry afterwards if the token went through it.
• Desktop: triple-click selects a line and click-drag selects the block. Ctrl+C on Windows and Linux, Cmd+C on a Mac.
• Never paste a production token into a chat. Messages are searchable, backed up and often retained for years. If you must demonstrate a token, issue one against a test account or use one that has already expired.

How different issuers and languages shape the same token

Every JWT follows RFC 7519, but issuers differ in what they put beyond the registered claims. At the time of writing:

• OpenID Connect providers issue an id_tokenthat is a JWT describing the sign-in, most often signed with RS256, alongside an access token whose format is not fixed by the spec. Their public keys and supported algorithms are published at the discovery document and key set URLs listed in the provider’s documentation.
• Auth0 requires custom claims to be namespaced with a URI, so a role list appears under something like https://example.com/roles rather than a bare roles key. If a custom claim seems to vanish, an unnamespaced name is the usual reason.
• Firebase Authentication ID tokens are signed with RS256. The sub is the Firebase UID, the aud is the project id, and a firebase object records how the user signed in.
• Supabase access tokens carry the user id in sub and a role claim that Postgres row level security reads through auth.uid(). Older projects sign with a symmetric project secret; newer ones can use asymmetric keys, so check your project settings before assuming which.
• Node: jsonwebtoken keeps decode and verify as separate functions on purpose. Reaching for decode in request handling code is the classic way to ship an authentication bypass.
• Python: PyJWT uses one function for both, so jwt.decode(token, options={"verify_signature": False}) is the read-only form and anything else needs a key and an explicit algorithm list.
• Shell: cut -d. -f2 <<< "$TOKEN" | base64 -d often fails, because base64url is a different alphabet and the padding has been stripped. Translate -_ back to +/ and add = signs until the length is a multiple of four.

Security, privacy and the limits of this page

Decoding is not verification. Nothing on this page checks a signature, so nothing here should ever be used to decide that a token is trustworthy. Never say a token is valid because a decoder rendered it. On the server, always verify with a library, always pass the algorithms you expect rather than trusting the alg field, and always check exp, iss and aud. The historic attacks on JWT come precisely from skipping those steps: a token re-signed with alg set to none, or an RS256 token replayed as HS256 so the public key is treated as a shared secret.

The payload is readable by anyone. Base64url hides nothing. Keep passwords, government id numbers, payment details and anything else you would not publish out of the claims. If the contents must be confidential in transit and at rest, that is what JWE is for, and a JWE has five segments rather than three.

A token cannot be taken back. Once issued, a JWT is accepted until it expires, because verifying it involves no lookup. Short lifetimes with a refresh token, a denylist of jti values, or a version number in the payload that you can bump are the three usual mitigations, and all three trade away some of the statelessness that made the format attractive.

What leaves your browser: nothing. The decode runs in this tab, and this site has no backend endpoint that could receive a token. That is a statement about this page, not about the rest of your workflow: the same token in a screenshot, a log file or a chat message is exposed regardless. When in doubt, decode an expired token, which has the same structure and none of the risk.