JWT Explained: What a JSON Web Token Actually Is

JSON Web Tokens (JWTs) sit behind most modern authentication flows — you have likely held one in your browser's storage without ever seeing it. This guide explains the three parts of a JWT, what they are for, and the security rule that trips up even experienced developers: decoding a JWT does not verify it.

The three parts

A JWT is a string with three base64url-encoded segments separated by dots:

header.payload.signature

• Header — metadata about the token: the signing algorithm (typically HS256 or RS256) and the token type.
• Payload — the claims: statements about the user and the token itself. Standard claims include sub (subject, the user identifier), exp (expiration timestamp), iat (issued at), and iss (issuer). Applications add custom claims too.
• Signature — a cryptographic value computed over the header and payload using a secret key (HMAC) or a private key (RSA/ECDSA). This is what lets a server detect tampering.

Encoding is not encryption

Base64url encoding is not encryption — it is a reversible text encoding. Anyone can decode the header and payload of any JWT and read its contents. Sensitive data should never be placed in a JWT payload expecting it to be hidden; the token's protection comes from the signature, which prevents modification, not reading.

Decoding versus verifying

Here is the critical distinction:

• Decoding — base64url-decoding the segments to read the claims. Anyone can do this with any JWT, no key required.
• Verifying — recomputing the signature with the expected key and checking it matches, plus checking claims like exp and iss. Only the server with the key can do this properly.

A decoder that shows you the payload is telling you what the token says, not that the token is valid. An attacker can craft a JWT with a forged payload; it will decode fine and fail verification. Never trust a token's contents based on decoding alone.

Security guidance

• Never paste production tokens into a server-side online decoder — the token may contain session data and the site may log it
• Prefer local decoding: a browser-based decoder like JWT Decoder processes the token entirely on your device
• Treat expired tokens as invalid — check exp against the current time during verification
• Use strong algorithms: prefer asymmetric RS256 over shared-secret HS256 for multi-service systems
• Keep payloads small and free of sensitive personal data

When to use JWT

JWTs shine for stateless authentication: the server validates the signature and trusts the claims without storing session state. They are a poor choice for storing sensitive data (they are readable), for long-lived sessions (rotation and revocation are awkward), and for anything where you cannot protect the signing key. For most client-side debugging — checking what a token claims, why a request is failing, whether a claim name is correct — a local JWT decoder is all you need, with your data staying on your machine.