What Is a JWT and How Do You Decode One?

A JWT is a text string signed by a server about a user, made of three parts. Split it apart and the middle section is usually readable and shows the user data, but that doesn't mean the signature is valid.

Summary

Step by step

Split the token at its dots into three parts: header, payload, signature.
Decode the middle payload section with a JWT decoder and read the fields inside (user ID, expiry, that kind of thing).
Check the "exp" field to see whether the token has expired.
Keep in mind that decoding isn't the same as verifying. Only the server that issued the token can actually confirm it's valid.

Why it matters

The first two parts of a JWT aren't encrypted. They're only Base64URL-encoded, so anyone who gets hold of the token can read what's inside. Putting passwords, card details or sensitive personal data in the payload is a real design mistake. Knowing how to decode a JWT lets you see what your own app is exposing, and it makes login problems much faster to diagnose.

Fields you'll often see in the payload

sub: the user or entity the token is about, usually an ID.
iss: who issued the token.
aud: which service the token is meant for.
iat: when the token was issued. nbf: the moment it starts being valid.
exp: when it expires. This and the other time fields are counted in seconds since 1 January 1970, so you'll need to convert them to a readable date.

Common mistakes

On the server, decoding the token and trusting its role claim without verifying the signature. Editing a payload is trivial.
Accepting whatever the header's alg field says. The server should accept only the algorithm it expects and reject unsigned values like "none".
Issuing long-lived tokens with no way to revoke them. A stolen token keeps working until it expires.
Pasting real production user tokens into online tools when you don't know how they handle the data.

A worked scenario

A front-end developer notices users getting 401 errors a few minutes after logging in. She copies the token from a request in the browser's developer tools and decodes it. Converting exp to a date shows the token expires just five minutes after it was issued. The bug isn't in her code at all, it's in the auth service's configuration. Clock drift could have been another culprit. If iat shows a time in the future, the server clock is the first thing to check.

After you decode

If a token contains a field you didn't expect, or something sensitive, flag it to whoever issues the tokens. Keeping the payload small and limited to what's needed is better for security and for performance, since the token usually travels with every request.