What a JWT Is For
A JSON Web Token, or JWT, is a compact, self-contained way to carry claims between two parties, most often to prove who a user is after they log in. Instead of the server storing session state and looking it up on every request, it hands the user a signed token. The user sends that token back with each request, and the server trusts it because the signature proves the token has not been tampered with. This makes JWTs popular for authentication in APIs and single-page apps, where keeping servers stateless is valuable.
The Three Parts of a Token
A JWT is a single string split into three sections separated by dots. Each section is Base64 URL encoded, which is why a token looks like random characters even though it holds readable data.
- Header describes the token itself, mainly the signing algorithm used, such as HS256 or RS256, and the token type.
- Payload carries the claims, the actual data, such as a user id, roles, and an expiration time.
- Signature is a cryptographic stamp created from the header, the payload, and a secret or private key. It is what lets the server verify the token is authentic.
You can see all three decoded at once with the JWT Decoder.
Encoded Is Not Encrypted
This is the single most important thing to understand about JWTs. The header and payload are only Base64 encoded, not encrypted. Anyone who has the token can decode and read the payload, so you must never put secrets, passwords, or sensitive personal data in it. The signature does not hide the contents; it only proves they were not changed. If you need the contents to be private, that requires a separate layer of encryption. You can confirm how encoding works for yourself with the Base64 tool.
How Verification Works
When a server receives a token, it recomputes the signature from the header and payload using its own secret or public key, then compares that to the signature attached to the token. If they match, the token is authentic and untampered. If even one character of the payload was changed, the recomputed signature will not match and the token is rejected. The signing itself relies on hashing, and you can explore how hash functions produce a fixed fingerprint with the Hash tool. Because verification depends on a secret, the security of the whole scheme rests on keeping that signing key private.
Common Claims in the Payload
Standardized claim names keep tokens interoperable. A few appear constantly.
- sub is the subject, usually the user id the token represents.
- exp is the expiration time, after which the token should be rejected.
- iat is the time the token was issued.
- iss is the issuer, the service that created the token.
When you decode a token, checking exp first tells you whether it is even still valid.
JWT Versus Traditional Session Cookies
It helps to see where JWTs fit compared with the older approach. With a traditional server session, the server stores the session data and gives the browser a small id in a cookie; every request looks that id up in server memory or a database. With a JWT, the data travels inside the token itself, so the server can verify it without a lookup. That statelessness is the JWT's main advantage: it scales cleanly across many servers because none of them need a shared session store. The tradeoff is revocation. A server session can be deleted instantly to log someone out, but a signed JWT stays valid until it expires unless you build extra machinery to block it. This is why short expiration times and refresh tokens are common in JWT systems.
Inspecting Tokens Safely
Developers debug tokens constantly, but a token can be a live credential. Pasting a production token into a random website means handing that site a working key to an account, and some sites log what they receive. A safer habit is to use a decoder that runs entirely in your browser, so the token never leaves your machine. The JWT Decoder works this way, and pairing it with the JSON Formatter makes the decoded payload easy to read.
Frequently Asked Questions
Can anyone read the data in a JWT? Yes. The payload is only encoded, not encrypted, so treat it as public and never store secrets in it.
What stops someone from forging a token? The signature. Without the server's signing key, an attacker cannot produce a valid signature for altered data.
Why did my token stop working? The most common reasons are that it expired, the exp time passed, or the signing key changed. Decode it and check the exp claim first.
Is it safe to decode a production token online? Only in a tool that runs in your browser. The JWT Decoder decodes locally so the token is not sent to a server, but still avoid untrusted devices.
Bottom Line
A JWT is three Base64 parts, header, payload, and signature, where the signature proves authenticity but the payload stays readable. Decode and inspect tokens safely with the browser-based JWT Decoder, and never put secrets in a payload.