Is my token sent to a server?

No. The three segments are Base64url-decoded by your browser and rendered in the page. Nothing is transmitted, which matters because a JWT is a live credential for as long as it is valid.

Why can it not verify the signature?

Because verification requires the signing key, and asking for one in a web form is a habit worth not building. Verify in your own code or on the command line, where the key stays on your machine.

No. The header and payload are Base64url-encoded, which is an encoding rather than a cipher. Anyone holding the token can read every claim in it. Never put anything confidential in one.

My token decodes fine but the API rejects it. Why?

Check exp first - an expired token decodes perfectly and is still refused. After that the usual causes are an aud or iss the recipient does not accept, or a signature made with the wrong key.

A jwt.io alternative that never asks you for the signing key

jwt.io is the page that taught most of us what a JWT is, and its decoder is excellent. It also has a box labelled secret, and the habit it teaches - paste the token, then paste the key that signs it, into a web page - is worth thinking about more carefully than most people do.

Open the JWT Decoder →

jwt.io and Softland, side by side

	jwt.io	Softland
Decoding header and claims	Yes	Yes
Signature verification	Yes, if you supply the key	Deliberately not offered
What you have to paste	The token, and a key if you want it verified	The token, and nothing else
Expiry	Shown	Shown, resolved against the current time
Library directory	Extensive, per language	None

The secret box is the interesting part

Verifying an HS256 token means having the symmetric key that signs every token your system issues. Typing it into a field on a web page is an odd thing to do with a credential of that weight, and people do it constantly, usually while debugging something urgent and not thinking about it at all. The token itself is already a bearer credential, but it expires. The signing key does not.

This decoder has no verification feature, so there is no field asking for a key and no moment where pasting one seems like the natural next step. That is a real reduction in capability and it is the point of the design rather than an omission.

What a decoder can honestly tell you

A JWT is three Base64url segments. The first two are plain, readable JSON - anyone holding the token can read every claim in it without any key at all. That is worth internalising, because it means a JWT is signed, not encrypted, and putting anything confidential in a claim publishes it to whoever holds the token.

So decoding answers the questions that actually come up: which issuer minted this, which subject is it for, which audience is it scoped to, and has exp already passed. The expiry check catches the single most common cause of a token being rejected, and it needs no key to perform.

Reading the token you were sent

The usual situation is that an integration is failing, someone has pasted a token into a ticket, and you need to know what is in it. That token belongs to a real session, and the fewer places it is typed the better. Decoding here happens in the page; nothing is transmitted, so the token does not acquire another copy on its way to being read.

If the answer turns out to be that the signature is wrong rather than that the claims are wrong, you need a verifier - and you should reach for one in your own code or on the command line, where the key never leaves the machine, rather than for any web page including this one.

When jwt.io is the better choice

You genuinely need to verify a signature and are working with a public key, where the exposure is far lower than with a shared secret.
You are learning how JWTs are structured and want the annotated, colour-coded breakdown that made the site famous.
You want the library directory to pick an implementation for your language.
You need to mint a test token rather than read an existing one.

Frequently asked questions

Is my token sent to a server?: No. The three segments are Base64url-decoded by your browser and rendered in the page. Nothing is transmitted, which matters because a JWT is a live credential for as long as it is valid.
Why can it not verify the signature?: Because verification requires the signing key, and asking for one in a web form is a habit worth not building. Verify in your own code or on the command line, where the key stays on your machine.
Is a JWT encrypted?: No. The header and payload are Base64url-encoded, which is an encoding rather than a cipher. Anyone holding the token can read every claim in it. Never put anything confidential in one.
My token decodes fine but the API rejects it. Why?: Check exp first - an expired token decodes perfectly and is still refused. After that the usual causes are an aud or iss the recipient does not accept, or a signature made with the wrong key.

Try it yourself

Decode a JSON Web Token and read its claims.

Open the JWT Decoder

jwt.io is a trademark of its respective owner. Softland is not affiliated with, endorsed by or sponsored by jwt.io. This comparison reflects how each product works rather than what either costs, because pricing and plan limits change; check jwt.io’s own site for its current terms.