What Is a JWT? Token Structure and Usage
In modern web applications, you don't have to re-enter your password on every page once you've logged in. The server hands you a "ticket" that identifies you, and you present this ticket with every request. The JWT (JSON Web Token) is today's most widely used form of that ticket. In this guide, we'll walk through what a JWT is, which parts it's made of, how it's used in the authentication flow, and which security points you need to keep in mind.
What Exactly Is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe standard (RFC 7519) used to securely transmit information between two parties. Its most common use is authentication and authorization.
A JWT carries JSON data embedded inside it, and this data is digitally signed. Thanks to the signature, the party receiving the token can verify that the content wasn't altered in transit. There's a critical point here: a JWT is not encrypted by default—it is only signed. In other words, the information inside it can be read by anyone; the signature only guarantees that it hasn't been tampered with.
The Token's Three Parts
A JWT consists of three sections separated by dots (.):
xxxxx.yyyyy.zzzzz
header.payload.signature
Each part is individually encoded with Base64Url. A typical token looks like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFobWV0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Although it looks meaningless at first glance, these three parts follow an orderly structure.
1. Header
The header usually contains two pieces of information: the type of the token (typ) and the algorithm used for signing (alg).
{
"alg": "HS256",
"typ": "JWT"
}
2. Payload
The payload carries the token's actual content—the statements known as claims. This is where information such as the user identity, roles, and expiration time lives.
{
"sub": "1234567890",
"name": "Ahmet Yılmaz",
"role": "admin",
"iat": 1748736000,
"exp": 1748739600
}
The commonly used standard claims are:
| Claim | Meaning |
|---|---|
iss |
The party that issues the token (issuer) |
sub |
The subject / user identity (subject) |
aud |
The intended recipients (audience) |
exp |
The expiration time (expiration) |
iat |
The time it was issued (issued at) |
nbf |
Invalid before this time (not before) |
Important: The payload is only Base64Url-encoded, not encrypted. For this reason, sensitive data such as passwords or credit card numbers must never be placed in the payload.
3. Signature
The signature is produced by combining the header and payload and processing them with a secret key. For the HS256 algorithm, it's calculated roughly as follows:
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
Every time the server receives the token, it recalculates the signature and compares it with the incoming one. If they don't match, the token is fake or has been altered, and it is rejected.
How Is a JWT Used in the Authentication Flow?
A JWT-based session usually works through these steps:
- Login: The user signs in with their email and password.
- Token generation: The server verifies the credentials, prepares the payload, signs it with the secret key, and generates a JWT that it sends to the client.
- Storage: The client stores the token (typically in an
HttpOnlycookie or in memory). - Requests: On every subsequent request, the token is sent in the
Authorization: Bearer <token>header. - Verification: The server checks the signature and claims such as
exp; if it's valid, it processes the request.
The biggest advantage of this approach is that it's stateless: the server doesn't need to keep session information for each user, because the necessary information lives inside the token. This makes horizontal scaling and microservice architectures much easier.
Decoding a Token Is Not the Same as Verifying It
You do not need the secret key to see the contents of a JWT. Since the header and payload are only Base64Url-encoded, anyone can decode and read them. If you want to quickly see what's inside a token during development, you can use our JWT Decoder tool, which runs in your browser, to turn the header and payload into readable JSON within seconds. The whole process happens entirely in the browser; your token is never sent to any server.
If you're dealing with only one part of the token—for example, if you want to decode the payload section separately—you can also decode the relevant part on its own with our Base64 Decoder tool, because each section is in fact a piece of Base64Url text.
It's important to keep this distinction clear:
- Decode: Makes the token readable. No key is required and it provides no security.
- Verify: Checks whether the signature is valid against the secret key. Since only the server holds the secret key, only the server can do this securely.
That's why being able to "decode" a token does not make it trustworthy. Never blindly trust the information you read on the client side; authorization decisions should always be made on the server, after the signature has been verified.
Security Notes
A JWT is a powerful tool, but when used incorrectly it can lead to serious vulnerabilities. The main points to watch out for:
- Don't store sensitive data: The payload is readable by anyone. Don't carry passwords, secret tokens, or sensitive personal information.
- Set a short lifetime: Give tokens as short a validity period as possible using the
expclaim. For long sessions, use a separate refresh token mechanism. - HTTPS is mandatory: Tokens must always be transmitted over an encrypted connection; otherwise a man in the middle can steal the token.
- Beware the
alg: nonetrap: Some libraries can be misconfigured to accept unsigned tokens. The server must explicitly enforce the algorithm it expects. - Use a strong secret key: For HS256, a short or predictable key can be cracked with brute-force attacks.
- Secure storage: Keeping the token in an
HttpOnlycookie rather thanlocalStoragein the browser is safer against XSS attacks.
Summary
A JWT is a signed but unencrypted token format consisting of three parts: header, payload, and signature. It makes stateless authentication easier, but since its contents can be read by anyone, it must be used with the right security measures. Keeping the difference between decoding and verifying in mind is the key to using JWTs safely.
If you're curious about exactly what's inside a token you have, you can try our free JWT Decoder tool, which runs entirely in your browser without sending any data to a server.
Related Tools
- JWT Decoder — Turn the header and payload sections of a JWT into a readable form in your browser.
- Base64 Decoder — Decode a single part of a token or any Base64 text.

