JWT (JSON Web Token) is the technology quietly handling login sessions and authentication behind an enormous share of modern web apps and APIs — every time you log into a site and it "remembers" you across requests without asking for your password again, there is a reasonable chance a JWT is doing the work. Despite being everywhere, most people who encounter one — a long string starting with "eyJ" — have no idea what it actually contains or how it works. This guide demystifies the structure.
The three-part structure
A JWT is a single string made of three parts separated by periods: a header, a payload, and a signature — written as header.payload.signature. Each of the first two parts is a JSON object that has been Base64-encoded into text, while the third part is a cryptographic signature that verifies the token has not been tampered with. This structure is exactly why a JWT always starts with "eyJ" — that specific sequence is what the JSON structure "{"..." looks like once Base64-encoded, making JWTs instantly recognisable once you know the pattern.
What the header and payload actually contain
The header typically specifies the token type and the signing algorithm used — small, structural metadata about the token itself. The payload is where the actual useful information lives: "claims" about the user or session, such as a user ID, an expiration time, and whatever other data the issuing system chose to include, like a username, role, or permissions. Because both of these are just Base64-encoded JSON — not encrypted — anyone who has the token string can decode and read both parts instantly, with no key or password required, exactly the same way Base64 in general is trivially reversible by anyone.
The crucial point: JWTs are readable, not secret
This surprises people the first time they realise it: the header and payload of a JWT are not encrypted and can be read by anyone who intercepts or otherwise obtains the token, using nothing more than a basic decoder. This means you should never put genuinely sensitive information — passwords, full card numbers, private personal data — directly into a JWT payload, since doing so is functionally equivalent to writing it in plain, readable text. The JWT Decoder shows you exactly this by decoding any JWT's header and payload instantly, which is a useful way to see for yourself how readable a token actually is — and a good practical check to run against any token your own application generates, to confirm you have not accidentally included something sensitive in the payload.
So what actually keeps a JWT secure?
If the content is readable by anyone, the security value of a JWT comes entirely from the signature, the third part of the token. The signature is generated by the issuing server using a secret key (or a private key, depending on the signing method) that only the server possesses, and it mathematically ties the signature to the exact content of the header and payload. If anyone tampers with the payload — changing a user ID or a permission claim, say — the signature no longer matches, and any system correctly verifying the token will reject it as invalid. This is the real security guarantee a JWT provides: not confidentiality of its contents, but integrity — proof that the token's contents have not been altered since the trusted server issued it, and that it genuinely came from that server in the first place.
Why expiration matters so much
Because a valid JWT, once issued, can be used by anyone who possesses it to prove the claims it contains (assuming the receiving system trusts the issuer), an expiration time included in the payload is a critical safety mechanism — it limits how long a token, if ever intercepted or leaked, remains usable. Well-designed systems set relatively short expiration windows and issue fresh tokens regularly (often using a separate, longer-lived "refresh token" mechanism to renew short-lived access tokens without requiring the user to log in again constantly). A JWT with no expiration, or an excessively long one, is a meaningfully weaker security design, since a leaked token remains a live risk for as long as it stays valid.
JWTs vs traditional session cookies
It is worth understanding what problem JWTs actually solve, since it explains why they became so widely used. Traditional session-based authentication requires the server to store session data and look it up on every request, which works well for a single server but becomes more complex to coordinate across multiple servers or services, as is common in modern distributed applications. A JWT is "self-contained" — all the information needed to verify who the user is and what they are allowed to do travels within the token itself, verified purely by checking the signature, without the server needing to look anything up in a shared session store. This makes JWTs well suited to distributed systems and APIs where multiple independent services need to verify a user's identity without all sharing direct access to the same central session database, which is the main reason they have become so prevalent in modern web and API architecture.
Practical situations where this understanding helps
Knowing how JWTs work is genuinely useful beyond pure curiosity. If you are debugging why an API call is failing with an authentication error, decoding the JWT you are sending can reveal whether it has expired, or whether it is missing an expected claim. If you are reviewing a system's security, checking what a JWT actually contains — and confirming nothing sensitive is embedded in the readable payload — is a quick, meaningful check. And understanding that the payload is readable but the signature prevents tampering clarifies a common point of confusion for anyone new to working with modern authentication systems, where "the token looks like gibberish" is often mistaken for "the token is encrypted," when it is really just Base64-encoded and freely readable by design.
Key takeaways
- A JWT has three parts — header, payload, signature — with the first two being readable, Base64-encoded JSON, not encrypted data.
- Anyone can decode and read a JWT's contents; never put sensitive data directly in the payload.
- The signature provides integrity (proof the token wasn't tampered with), not confidentiality of its contents.
- Short expiration times limit the damage if a token is ever intercepted or leaked.