How to Decode a JWT and Read Its Claims: What Is Inside, and What the Signature Does Not Tell You

You log in to an app, and later in the developer tools you spot a long string starting with the letters eyJ and containing two dots. That is a JWT. You assume it is encrypted and unreadable, then discover you can read most of it in seconds with no key at all. That discovery carries an important security lesson, and we will get to it.

Three parts separated by two dots

A JWT has three parts, each written in URL-safe Base64:

• The header: says which algorithm was used to sign it, and the token type.
• The payload: the fields the token carries, called claims: who the user is, when the token was issued, when it expires.
• The signature: a hash computed from the first two parts with a secret key, whose purpose is to detect tampering.

The first two parts are not secret. They are simply encoded, which is why Sahel's JWT decoder opens them instantly and shows them readably. And that is the key point: whatever goes inside a JWT is visible to anyone who holds it, so never put a password or sensitive personal data in one.

The fields you will usually see

Most tokens carry a set of standard, short-named claims:

• sub: the subject, usually a user ID.
• iss: the issuer, the party that created the token.
• aud: the audience, the party the token is meant for.
• iat: the time it was issued.
• exp: the expiry time, the one people ask about most.
• nbf: the time before which the token is not valid.

The times in these fields are stored as long numbers — seconds since the start of 1970 — which a person cannot read directly. The tool converts them to readable dates and tells you whether the token has expired right now. If you want to convert a number like that yourself, use the timestamp converter.

Decoding versus verifying

This is the most important idea in the article. Decoding means reading the contents, and it is open to everyone. Verifying means confirming the signature is correct — that the token really came from the party it claims and not a character has changed. Verification needs the issuer's secret or public key.

The tool does not verify the signature and does not ask for your key, and that is deliberate. A secret key does not belong in a web page under any circumstances, and any tool that asks you for one should make you suspicious.

The practical consequence: when the tool shows a token with sensible claims and a believable expiry, that does not mean the token is valid. The content may have been edited after signing, or the whole token may have been forged by someone else. Only the server, holding the key, decides validity.

Common security mistakes with JWTs

Taking a token apart sometimes exposes design problems rather than tool problems. The most frequent:

• Sensitive data inside the token: a full phone number, an address, or an admin role the user should not know about. Everything in the payload is readable by its holder.
• A very long lifetime: a token that lasts months means a stolen one gives an attacker a long window before it stops working.
• The "none" algorithm: a header claiming the token is unsigned. A sound server always rejects it, and seeing it in a real token is a serious warning sign.
• Trusting the front end alone: reading the role from the token in the browser to hide a button is fine for display, but the actual permission decision must be made on the server.

How to use it

1. Copy the whole token from a login response or a request header. Remove the word Bearer if it is stuck to the front.
2. Paste it into the tool.
3. Read the header and claims, and look at the issue and expiry times and whether that time has passed.
4. If an error appears, the part count is most likely not three, or the copy was cut off partway.

A realistic scenario

A front-end developer complains that users are being logged out of the app shortly after signing in. They paste the token the server returns into the tool and see that the gap between iat and exp is only fifteen minutes. The fault was never in the front end; it was the server's configured lifetime. They then notice that the aud claim points at a different service from the one their app calls, which also explains why some requests are rejected after a token refresh. All of it appeared within a minute, with no key and no need to read the server's code.

Frequently asked questions

Is my token sent to a server?

No. Decoding runs entirely in your browser. That matters because a valid login token gives its holder the owner's permissions until it expires, so pasting it into a site that forwards it elsewhere is a real risk.

Can I use a real token from a live account to test?

A test or already-expired token is better. If you must inspect a live one, the tool does not transmit it, but avoid pasting it anywhere else and end the session afterwards if you can.

Why does it say expired when I am still logged in?

You may be looking at a short-lived access token while your session persists thanks to a separate refresh token that quietly issues new ones. The two facts do not conflict.

What causes an "invalid format" message?

Common causes: copying only part of the token, pasting the word Bearer along with it, stray spaces or line breaks, or the string not being a JWT at all but an opaque token of another kind that cannot be read.

Is a JWT encrypted?

The common kind is signed, not encrypted, so its contents are readable by anyone holding it. Encrypted forms exist but are rare; they have five parts rather than three, and an ordinary decoder cannot read them without the key.