Stop Pasting Your JWT Into Random Websites Just to Read It
A 401 error appears in the logs, the access token is sitting in the request headers, and the quickest way to see what is inside it is to paste it into the first online decoder in the search results. It works in seconds. It also sends a live credential to a server the developer knows nothing about.
A JWT is readable by design
A JSON Web Token has three parts separated by dots: a header, a payload and a signature. The first two are base64url-encoded JSON. They are not encrypted. Anyone holding the token can read the claims inside it: who it belongs to (sub), who issued it (iss), who it is meant for (aud), when it expires (exp), and any custom claims such as an email address or a role. No secret is needed for any of that. The secret or public key only matters when the signature has to be checked.
Why the paste matters
An unexpired access token behaves like a password until it runs out. Any site that receives it in a request could, in principle, record it. Most decoders probably do not, but from the outside there is rarely a way to tell. The safer habit is to decode where nothing leaves the machine. A decoder that runs entirely in the browser can be checked in under a minute: open the Network tab, paste a token, and confirm that no request carries it.
Decoding is not trusting
Seeing “role”: “admin” in a payload proves nothing, because anyone can build a token that says so. Only signature verification, using the correct shared secret or the issuer’s public key, shows that the token came from the expected server and was not modified. Two cases are worth knowing:
- A token with alg: none has no signature at all. Anyone could have created or altered it, and servers should reject it.
- A token with five dot-separated parts is an encrypted JWE, not a signed JWT. Its contents cannot be read without the decryption key.
The expiry check that saves time
The exp claim is a Unix timestamp, which is not easy to read at a glance. When an API answers with “jwt expired”, converting exp to local time and comparing it with the server’s clock usually settles the question quickly. The nbf (“not before”) claim works the same way and explains tokens that are rejected for being used too early.
A short checklist
- Decode locally, never on a site that uploads the token.
- Treat decoding as reading, not as verifying.
- Check exp and nbf before blaming the API.
- Reject alg: none tokens.
A free JWT decoder and expiry checker that runs entirely in the browser, shows a live countdown to expiry and can verify HS256, RS256 and ES256 signatures is available on Blogs Byte.
Get Bilalsarwar’s stories in your inbox
Join Medium for free to get updates from this writer.
Visit Our Website: BlogsByte
