What Is a JWT Token and How Does It Work

JWTs (JSON Web Tokens) are everywhere in modern web authentication, and understanding their actual structure — rather than treating them as an opaque “login token” — clarifies both why they’re useful and a genuinely common security mistake that comes from misunderstanding what a JWT does and doesn’t guarantee on its own.

The three-part structure

A JWT is a single string made of three parts separated by periods: header.payload.signature. Each of the first two parts (header and payload) is a JSON object encoded using Base64URL (a URL-safe variant of Base64 encoding) — meaning they’re not encrypted, just encoded, and can be decoded by anyone with the token, without needing any secret key.

The header typically identifies the token type and the signing algorithm used. The payload (sometimes called claims) carries the actual data — commonly things like a user ID, an expiration timestamp, and whatever other information the issuing system decided to include. The signature is the genuinely important cryptographic part: it’s generated by combining the header and payload with a secret key (known only to the issuing server) and running them through the specified signing algorithm, producing a value that lets anyone holding the correct key verify the token hasn’t been tampered with since it was issued.

Decoding is not the same as verifying

This is the single most important distinction to understand about JWTs, and it’s the source of a genuinely common and serious security mistake. Decoding a JWT — reading the header and payload — requires no secret at all, since Base64URL encoding is fully reversible by design, not encryption. Anyone who has a JWT string can decode and read its payload contents freely, whether or not they have any right to trust that token’s authenticity.

Verifying a JWT is a completely separate operation: recomputing the signature using the secret key and confirming it matches the signature embedded in the token. Only verification actually confirms the token is genuine — that it was really issued by the expected server and hasn’t been altered since. A token that decodes cleanly (readable header and payload) tells you nothing about whether it’s genuine; a forged or tampered token decodes exactly as easily as a legitimate one, since decoding doesn’t check the signature at all.

Why this distinction is a real security risk

The practical danger is straightforward to state: an application that decodes a JWT’s payload and trusts its contents (say, a claimed user role or permission level) without separately verifying the signature is trusting completely unauthenticated, attacker-controllable data. Anyone can construct a JWT with a payload claiming to be an administrator, and it will decode just as cleanly as a legitimate token — the payload contents are only trustworthy once the signature has been independently verified against the correct key, confirming the token genuinely came from the expected issuer and hasn’t been modified.

This is exactly why any tool, including the one on this site, that decodes a JWT’s contents for inspection should be explicitly clear that it performs decoding only, not verification — reading a JWT’s claims for debugging or understanding what a token contains is a legitimate, common use case, but that decoded content should never be treated as proven-authentic without the separate signature verification step, which requires the actual secret or public key used to sign it.

Why JWTs are structured this way

The self-contained design — where the token itself carries the claims, rather than requiring a server-side lookup on every request to check a session store — is exactly what makes JWTs attractive for distributed and stateless authentication systems. A server receiving a request can verify a JWT’s signature and trust its claims without needing to query a central database or session store, which scales well across multiple servers or services that all share the same signing key or public key, without needing shared session state between them.

Working with JWTs directly

The JWT Decoder on this site decodes a token’s header and payload for inspection — explicitly labeled as decode-only, matching the important distinction covered here. For understanding the encoding mechanism underneath a JWT’s header and payload, the Base64 Encoder covers the same Base64-family encoding directly. Since JWT-based systems commonly protect the signing secret itself with a password or key, the Password Strength Calculator and the Password Security Explained article on this site cover the adjacent question of how to keep that underlying secret genuinely secure.