If you've ever pasted an eyJhbGciOi... string into a chat message to ask "why isn't this working," you already know the problem: a JWT is unreadable as-is. It's not encrypted, but it is Base64URL-encoded, so you can't just eyeball it — you need to decode it first.
Here's what's actually inside a JWT, how to decode one in seconds, and the one mistake almost everyone makes when debugging auth issues with them.
What a JWT Actually Is
A JSON Web Token is three Base64URL-encoded parts joined by dots:
header.payload.signature
- Header — the algorithm used to sign the token (e.g.
HS256,RS256) and the token type. - Payload — the actual claims: user ID, roles, expiry time, issuer, and whatever else the API put in there.
- Signature — a cryptographic signature over the header and payload, used to verify the token hasn't been tampered with.
The header and payload are just Base64URL-encoded JSON — anyone can decode them with nothing more than a text editor and a bit of patience. The signature is the part that actually requires the secret key to verify.
How to Decode One
- Copy your JWT (the full string, including both dots).
- Paste it into JWT Decoder.
- The header and payload appear instantly as readable JSON — no signup, no upload, nothing leaves your browser.
That's it. No installing a CLI tool, no atob() in a browser console, no third-party site logging your production tokens.
Reading the Payload: Common Claims
Most payloads share a handful of standard fields:
| Claim | Meaning |
|---|---|
sub | Subject — usually the user ID the token represents |
iat | Issued At — Unix timestamp of when the token was created |
exp | Expiration — Unix timestamp of when the token stops being valid |
iss | Issuer — which service or auth server created the token |
aud | Audience — which service the token is intended for |
role / scope | App-specific — permissions or roles granted to the user |
iat and exp are Base64-decoded fine, but they're still just numbers (seconds since epoch) — run them through an Unix Timestamp Converter to see the actual date and time, especially when you're debugging "why did my session expire early."
Decoding Is Not Verifying
This is the mistake that trips people up: decoding a JWT tells you what it claims, not whether those claims are trustworthy.
Anyone can take a JWT's header and payload, edit the JSON, re-encode it, and produce a token that "decodes" into whatever they want. What stops that from being a security hole is the signature — and checking the signature requires the server's secret key (for HS256) or public key (for RS256). A decoder tool that just shows you the JSON is not doing that check.
In practice this means:
- Client-side decoding is fine for reading your own token during development — checking what claims your login endpoint actually returned, confirming an expiry time, debugging a role that isn't showing up.
- Never trust a decoded JWT's claims as authorization proof without server-side signature verification. If your backend isn't verifying signatures on every request, decoding is the least of your problems.
Common Things People Debug With a Decoder
"Why does my API call return 401 Unauthorized?"
Decode the token and check exp against the current time. Expired tokens are the single most common cause — and it's an easy check once you can actually read the timestamp.
"Why doesn't my user have the role I assigned them?"
Decode the payload and check whether the role or scope claim is actually there. Often the frontend is reading a stale token cached before a permissions change — the new role exists in the database but not in the token still sitting in local storage.
"Which environment issued this token?"
Check the iss claim — useful when staging and production tokens look identical at a glance but come from different auth servers.
Quick FAQ
Is it safe to paste a production JWT into an online decoder? Only if the tool decodes entirely in your browser and never sends the token to a server — check that before pasting anything with real user data. JWT Decoder processes the token client-side.
Can I re-encode a JWT after editing the payload? You can produce a token that looks like a valid JWT, but without the correct signing secret, any server doing proper signature verification will reject it. Editing a decoded payload is only useful for testing/debugging tools, never for bypassing real authentication.
Why does the same token look different every time it's issued?
If iat (issued at) is part of the payload, every freshly issued token has a different timestamp even if every other claim is identical — that alone changes the encoded string.
What's the difference between HS256 and RS256? HS256 uses one shared secret to both sign and verify — same key on both ends. RS256 uses a private key to sign and a separate public key to verify, which is why it's more common for tokens verified by multiple services.
Related Free Tools
- JWT Decoder — decode header and payload instantly
- Unix Timestamp Converter — turn
iat/expnumbers into readable dates - JSON Formatter — pretty-print the decoded payload if you're inspecting it elsewhere
- Hash Generator — generate hashes for comparing token integrity in other contexts
- Base64 Encoder — manually encode/decode individual JWT segments