How to Read a JWT

A JSON Web Token, or JWT, is three base64url chunks joined by dots, and you read it by splitting on those dots and decoding the first two parts back into JSON. The third part is a signature, not readable text. The single most important thing to understand before you read one is that the payload is only encoded, not encrypted. Anyone holding the token can decode it and see every claim inside, so a JWT is never a place to store a password, an API key, or anything else you would not hand to a stranger. You can decode any token instantly in your browser with Quialo's JWT decoder, which runs locally and never uploads the token.

The Three Segments

A JWT always has this shape:

header.payload.signature

Each segment is separated by a dot. A sample token (fake, for illustration only) looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQXZhIn0.5fGhKq2pT8wXyZ

Notice the two dots. Splitting on them gives you the header, the payload, and the signature in that order. The header and payload are base64url-encoded JSON. The signature is a base64url-encoded set of bytes that proves the token has not been tampered with.

Reading the Header

The header is the first segment. Decode it from base64url and you get a small JSON object that describes how the token was built:

{
  "alg": "HS256",
  "typ": "JWT"
}

The alg field names the signing algorithm, such as HS256 or RS256. The typ field is usually just JWT. The header tells a server how to verify the signature later, so it is mostly of interest to the system checking the token rather than to a person reading it.

Reading the Payload

The payload is the second segment and the part most people actually want. Decode it from base64url and you get JSON full of claims:

{
  "sub": "123",
  "name": "Ava",
  "iat": 1716239022,
  "exp": 1716242622
}

Claims are simply named pieces of information. Some are standard: sub is the subject (often a user id), iat is the issued-at time, and exp is the expiry time. Both iat and exp are Unix timestamps, the number of seconds since the start of 1970, which is why they look like large numbers rather than dates. The rest of the claims are whatever the issuer chose to include, such as a name, a role, or a tenant id.

The Payload Is Encoded, Not Encrypted

This is the point worth repeating, because getting it wrong leads to real security problems. base64url is an encoding, not encryption. It rewrites bytes into a URL-safe alphabet so the token can travel in a header or a link, and that rewrite is completely reversible by anyone, with no key and no secret. If you would like the full picture of how that alphabet works, see our guide on base64 vs URL encoding.

In plain terms: every person and every system that receives a JWT can read its payload. Paste the middle segment into the JWT decoder and the claims appear in seconds, no password required. So never put secrets in the payload. A token can safely carry a user id, a role, or an expiry. It should never carry a password, a credit card number, a private key, or anything that would cause harm if it were read.

What the payload does NOT tell you is whether the token is genuine. That is the signature's job.

What the Signature Does

The signature is the third segment, and unlike the first two it is not human-readable JSON. It is created by signing the header and payload together with a secret key (for HS256) or a private key (for RS256). When a server receives the token, it recomputes the signature using the same key and checks that it matches.

This is what makes a JWT trustworthy even though anyone can read it. If someone changes a single character in the payload, say flipping a role from user to admin, the signature no longer matches and the server rejects the token. So the signature does not hide the contents. It guarantees the contents have not been altered since the issuer signed them.

How to Read One Safely

To read a JWT by hand, split it on the dots, take the first two segments, and decode each from base64url to JSON. You can also paste the whole token into the JWT decoder, which splits and decodes it for you and runs entirely in your browser, so the token is never sent anywhere.

One caution: because the payload is plainly readable, treat any token you find in logs, URLs, or screenshots as exposed. If a real token leaks, the safe assumption is that someone has already read everything inside it.

Frequently Asked Questions

Can anyone read the contents of a JWT? Yes. The header and payload are base64url-encoded, which is fully reversible with no key. Anyone holding the token can decode and read both segments, so they offer no privacy at all.

Is the JWT payload encrypted? No. It is encoded, not encrypted. base64url only rewrites the bytes into a URL-safe form. Never store a password, secret, or anything sensitive in a JWT payload, because it can be read by anyone.

What stops someone from editing a JWT? The signature. It is computed over the header and payload using a key the issuer holds. Change any character and the signature no longer matches, so the verifying server rejects the token.

What do iat and exp mean? They are Unix timestamps measured in seconds since the start of 1970. iat is when the token was issued and exp is when it expires. A verifier compares exp against the current time and refuses tokens that have passed it.

Do I need to send my token to a website to decode it? No. The Quialo JWT decoder runs entirely in your browser, so nothing is uploaded. Even so, treat any token you paste anywhere as readable, and rotate it if there is any chance it has leaked.