JWT Tokens Explained: What They Are and Why You Can Trust Them

by Souy Soeng /October 22, 2026

Diagram of a JWT split by dots into header, payload and signature, with labels explaining each part

A JWT, or JSON Web Token, is a compact string that carries signed information about a user, and it is often the thing that keeps you logged in to a website or app. With JWT tokens explained step by step, you will see that the idea is simpler than the random-looking letters suggest: it is a signed note about who you are.

This guide follows that note from start to finish. You will learn why websites need it, what its three parts do, how a server creates and checks it, where you meet JWTs every day, and the three mistakes that cause most JWT problems.

In short

A JWT is a compact, signed string that carries facts about a user.
It has three parts, header, payload and signature, separated by dots.
Anyone can read the payload; the signature is what makes it trustworthy.
Servers must check the signature and expiry before trusting a token.
Never put passwords or private data inside a JWT.

How does a website remember that you're logged in?

You log in to an online shop, close the tab, come back later, and you are still logged in. It feels effortless, but behind the scenes the server is solving a real problem each time you click. Something has to carry proof of who you are between visits.

The reason is that every request is separate. When you open a new page, the server does not automatically remember your last click. Each request arrives on its own, a bit like a stranger knocking on the door again and again.

So the server needs proof on every single request. If it gets this wrong, someone else could act as you, see your orders or change your account details. A JWT is one of the most common ways to provide that proof.

Each click sends a fresh, separate request.
The server must confirm who you are every time.

What is a JWT (JSON Web Token)?

A JWT is a compact string that carries signed information about a user. The name explains itself: JSON is the simple text format the data is written in, Web means it is designed to travel over the web, and Token means a small pass you carry around.

It is compact because it is just one line of text, with no files or special formats. That makes it easy to send in a web request, store inside an app, or pass between different services.

It is signed because the facts inside, such as who you are, are sealed with a signature. Think of a note signed by a manager: the paper itself proves nothing, but the signature tells you the note is genuine and can be trusted.

Why use JWTs instead of classic sessions?

JWTs exist so servers can verify users without keeping a record for every login. With classic sessions, the server stores data for each login and looks it up on every request. More users means more data to store and search.

With a JWT, the token itself carries the user information, and the server only checks the signature. It works like a festival wristband: security staff do not search a guest list every time you walk past. They glance at your band, see it is genuine and let you in.

Because nothing is stored per login, any server that can check the signature can verify you. This is especially handy when an application runs on many servers at once, since they do not all need access to one shared list of sessions.

Classic sessions: the server stores and looks up data for each login.
JWT: the token carries the data; the server checks the signature.
Result: easier to grow across many servers.

What does a JWT look like? Header, payload and signature

If you have ever seen a long string of random-looking letters with two dots in it, you have probably seen a JWT. Split it on the dots and you get three pieces: the header, the payload and the signature.

Once decoded, each part has a clear job. The header names the signing method, for example HS256. The payload holds facts about the user, such as a subject id like 1234. The signature is raw data that acts as the seal over everything else.

One point surprises many beginners: decoding is not decrypting. The header and payload are only encoded, so anyone who gets the token can read them in seconds. The signature is calculated from the header and payload using a secret, so if someone edits even one letter, the seal no longer matches.

Header: how the token is signed.
Payload: facts about the user.
Signature: the seal that reveals tampering.

How a server creates and signs a JWT

A token is created once, at login, and then reused for later requests. First, you prove who you are, usually with a username and password. No valid login means no token.

Once the password checks out, the server builds a payload containing the user id and an expiry time. It then signs that payload with a secret that only the server knows. Without that secret, nobody can produce a valid signature, which means nobody can forge a token.

Finally, the server sends the token back to the client. The browser or mobile app keeps it, and from then on it acts as your pass for every request you make.

Check the login.
Build a payload with user id and expiry.
Sign it with a server-only secret.
Send the token to the client.

# after the password checks out
const payload = { sub: '1234', exp: expiry }
const token = jwt.sign(payload, SECRET);
# send it back to the client
res.json({ token });

How is a JWT sent and verified on each request?

After login, the client attaches the token to every request. Most APIs expect it in the Authorization header, written as the word Bearer followed by the token. Bearer means whoever holds it gets in, so treat it like a house key.

Before trusting anything inside, the server checks the token. It splits it into three parts, recomputes the seal with its secret (for example using HMAC) over the header and payload, and compares the result with the signature it received. Then it checks the expiry. Only if both pass does it trust the user, such as user 1234.

If the seals do not match, the token was changed or forged, and the server rejects it, typically with a 401 response. If the token has expired, it is rejected too, even with a valid signature. That limits the damage if a token is ever stolen.

Split the token into three parts.
Recompute the signature with the secret.
Compare it with the received signature.
Check the expiry, then trust the user.

Where are JWTs used? APIs, single sign-on and mobile apps

You probably use JWTs every day without noticing. Web APIs use them to know who is calling. Single sign-on uses them so one login works across several sites. Mobile apps use them to keep you logged in. The pattern is the same everywhere: signed once, checked wherever it is presented.

Take a mobile app login. You tap Log in, and the app sends your password to an auth server. That server checks the password and signs a token containing details such as sub: 1234, an expiry and a signature. The app then sends that token to the API server, which checks it on every request.

Because the app stores the token, you do not have to type your password each time. When the token expires, you simply log in again and receive a fresh one.

Common JWT mistakes and how to avoid them

JWTs are simple, but they are easy to misuse. The first mistake is putting secrets in the payload. Many developers assume nobody can read their token, but anyone holding it can decode the payload. Never store passwords, keys or private details there; keep it to things like a user id.

The second mistake is skipping expiry. A token without an expiry works forever, so a stolen one becomes a permanent key. Always set an expiry, and always check it when verifying.

The third mistake is weak verification. Reading the payload without properly checking the signature means trusting anyone who sends a token. Use a well-tested library and verify every token, every time.

Keep secrets out of the payload.
Always set and check an expiry.
Verify signatures with a trusted library.

Key takeaways

A JWT is a compact, signed string about a user.
It removes the need to store session data for every login.
It has three parts, header, payload and signature, split by dots.
The server signs it at login; the client sends it back with each request.
Always verify the signature and expiry before trusting it.
Anyone can read the payload, so never put secrets in it.

Frequently asked questions

Is a JWT encrypted?

No. The header and payload are only encoded, so anyone who has the token can decode and read them. The signature protects against changes, not against reading.

What happens if someone edits a JWT?

The signature is calculated from the header and payload with a secret, so any edit makes it stop matching. When the server recomputes the seal and finds a mismatch, it rejects the request.

Where is a JWT sent in an API request?

Most APIs expect it in the Authorization header, after the word Bearer. Because whoever holds a bearer token can use it, it should be kept safe.

Why should a JWT have an expiry?

Without an expiry, a token works forever, so a stolen token becomes a permanent key. An expiry makes old tokens stop working even when their signature is valid.

What should I put in a JWT payload?

Keep it to non-sensitive facts the server needs, such as a user id and an expiry time. Passwords, keys and private details do not belong there.

Watch the full video on YouTube →

Tag

Ad