What Is a JWT (JSON Web Token), Really?

Paste a JWT into a decoder and the payload comes back as plain, readable JSON — no key, no password, nothing. That surprises people who assumed the long, scrambled-looking string meant it was encrypted. It isn't. A JWT is signed, not sealed, and the difference matters for what you should and shouldn't put inside one.

The three parts

A JWT is three Base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm, the payload holds the actual claims — user ID, roles, an expiry time, whatever the issuer decided to include — and the signature is a cryptographic stamp over the first two parts. Decode the header or payload and you get straightforward JSON back; it's the same underlying idea as our Base64 encoding guide, applied to two JSON objects stitched together with a signature.

What the signature actually protects

The signature proves the token wasn't altered after the issuer signed it, and (for algorithms like RS256) that it really came from whoever holds the private key. It does not hide the payload from anyone who receives the token. Anyone holding a JWT can decode and read every claim inside it — the signature is there to catch tampering, not to keep secrets. A server that trusts a JWT is trusting the signature, not the fact that the content is unreadable, because it isn't.

Decoding vs verifying — a distinction worth keeping straight

Decoding just splits the token on its dots and Base64-decodes the header and payload — no key needed, which is what a JWT decoder tool does. Verifying is a separate, stronger check: recomputing the signature with the correct secret or public key and confirming it matches, which is what a server has to do before it trusts the claims at all. A tool that only decodes will happily show you the contents of an expired or outright forged token — reading the payload was never proof the token is valid.

The mistake this misunderstanding causes

Because a JWT looks encoded, it's tempting to stash something sensitive in the payload — an email address is usually fine, a password or an API key is not. Anyone who intercepts the token, or who the token is legitimately sent to, can read every claim inside it in one step. Treat a JWT's payload as visible to the token holder by design, the same way you'd treat a signed but unsealed envelope.

The practical rule

Use a JWT's payload for claims that are fine to be readable — identity, permissions, expiry — and rely on the signature only to detect tampering, never to provide confidentiality. If something genuinely needs to stay secret from the token holder, it doesn't belong in a JWT at all.

Our JWT Decoder splits a token into its header and payload instantly in your browser, so you can inspect exactly what's inside one without sending it anywhere.