How to read a JWT (without verifying it)

A JSON Web Token (JWT) looks like a long random string, but most of it is readable in seconds. A signed JWT is not encrypted: the header and payload are just base64url, so anyone holding the token can decode them. Here is how to read one, and the important part that reading does not give you.

The three parts of a JWT

A JWT is three base64url segments joined by dots:

header.payload.signature

• Header: names the signing algorithm and token type, for example

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

• Payload: the claims, such as the subject (sub), issued-at time (iat),

expiry (exp), and any custom fields.

• Signature: a value computed over the header and payload using a secret or

private key. This is what protects the token from tampering.

The header and payload use base64url rather than standard Base64 because tokens travel in URLs and HTTP headers. If that distinction is new, see Base64 vs base64url.

Reading the header and payload

To read a JWT by hand, split it on the dots and base64url-decode the first two parts. Each decodes to plain JSON. In practice it is faster to paste it into a decoder.

A good decoder shows the header and payload as formatted JSON and highlights useful claims like exp (when the token expires) and iat (when it was issued). The signature stays encoded, since you cannot do anything useful with it by eye.

Decoding is not verifying

This is the part that matters most. Decoding a JWT tells you what it claims. It does not tell you whether those claims are true.

• Decoding base64url-decodes the header and payload. Anyone can do it. It

proves nothing.

• Verifying recomputes the signature using the issuer's key and checks it

against the token. Only a verified token's claims should be trusted.

Because anyone can decode and even craft a payload, a server must always verify the signature (and check exp) before acting on a token. Treating decoded claims as trusted is a common and serious security mistake.

Safety tips when reading tokens

• Never put secrets in the payload. It is readable by anyone with the token.

A JWT is encoding plus a signature, not encryption. The encoding vs encryption vs hashing guide explains the difference.

• Use a browser-based decoder so the token never leaves your device.
• Avoid pasting live production tokens into services you do not control. A

valid token can grant access until it expires.

• Check the expiry. A decoded exp in the past means the token should no

longer be accepted.

Key takeaways

• A signed JWT is not encrypted. Its header and payload are base64url and anyone

can read them.

• A JWT has three dot-separated parts: header, payload, and signature.
• Decoding shows what a token claims. Verifying the signature is what proves the

claims are authentic.

• Servers must verify the signature and check expiry before trusting any claim.
• Never store secrets in a JWT payload, and prefer a client-side decoder.