JWT Tokens: What They Are and How to Read One

Log in to almost any modern app and somewhere behind the scenes, a JWT starts vouching for you. JWT (JSON Web Token, usually pronounced "jot") is the standard way apps remember who you are without asking for your password on every click. If you build, test, or debug anything web-related, being able to read a JWT is a genuinely useful skill.

The shape of a JWT

A JWT is one long string with two dots in it, splitting it into three parts:

xxxxx.yyyyy.zzzzz

• Header — says what kind of token this is and which signing method it uses.
• Payload — the actual information: who you are, what you may do, when the token expires.
• Signature — a cryptographic stamp proving the token was not tampered with.

The header and payload are just Base64-encoded JSON — which means you can read them. The signature is the only cryptographic part.

Decoding one

Paste any JWT into the JWT Decoder and it instantly shows the header and payload as readable JSON. The decoding runs in your browser, so the token never leaves your machine — exactly what you want, since tokens are credentials.

A typical payload looks like:

{
  "sub": "user_12345",
  "name": "Jane Doe",
  "role": "admin",
  "iat": 1783500000,
  "exp": 1783503600
}

The short names are standard: sub is the subject (the user), iat is when the token was issued, exp is when it expires. Those timestamps are Unix time — convert them to readable dates with the Timestamp Converter.

The two facts everyone gets wrong

One: JWTs are not encrypted. The payload is only Base64-encoded, which anyone can reverse. Never put secrets — passwords, card numbers, private details — inside a JWT payload. Anyone who sees the token sees everything in it.

Two: decoding is not verifying. Reading a token tells you what it claims. Only checking the signature (which requires the secret key, on the server) tells you whether the claim is genuine. A decoder is a reading tool, not a security check.

When decoding a JWT saves your day

"Why am I logged out?" Decode the token, look at exp, convert the timestamp — the token expired ten minutes ago. Mystery solved: the app's refresh logic is broken.

"Why can't this user access the admin page?" Decode their token: "role": "viewer". The bug is not in the page's code; the token was issued with the wrong role.

"Which environment issued this token?" The iss (issuer) field says staging, but you are testing against production. That is your bug.

In all three cases, thirty seconds of reading the token replaced an hour of guessing.

For the builders: creating test tokens

If you are developing an API, you sometimes need a token with specific claims to test a scenario — an expired token, an admin role, a weird edge case. The JWT Encoder builds signed tokens from any payload you give it, which makes testing authorization logic much less painful.

Sensible token hygiene

Treat JWTs like passwords in transit: do not paste them into public chat channels, bug reports, or screenshots — remember, everything inside is readable. When sharing a token for debugging, share the decoded payload with sensitive values removed instead.

The takeaway

A JWT is three Base64 chunks in a trench coat: readable header, readable payload, unforgeable signature. Decode tokens freely to debug login issues, check roles, and read expiry times — just never mistake "readable" for "secure", and never put anything in a payload you would not write on a postcard.

Quick answers

Is it safe to paste a token into the decoder? Yes — decoding runs entirely in your browser and the token is never transmitted. Still, treat live production tokens like passwords and prefer expired ones for demos.

Why does my token show a weird date like 1783500000? That is Unix time — seconds since January 1, 1970. Convert it to a readable date and the mystery evaporates.

Can I edit a token to give myself admin? You can edit the payload, but the signature will no longer match, and any correctly built server will reject it instantly. That is the entire point of the signature.