What Are JWT Tokens and How Do They Work?
A simple guide to understanding how websites prove who you are using special tokens.
What a JWT Token Actually Is
When you log into a website, how does the website remember who you are as you click around? It can't ask for your password on every single page — that would be annoying and slow. Instead, the website gives your browser a special JWT token (short for JSON Web Token). Think of it like a temporary backstage pass. It says "this person is allowed to be here" without needing to check their ID every time they walk through a new door.
A JWT is just a string of random-looking characters that the website can read and verify. It has three parts, separated by dots:
- Header — says what kind of token it is and which algorithm was used to sign it
- Payload — contains the actual data, like your user ID and username
- Signature — a secret stamp that proves the website created this token, not someone pretending to be the website
Each part is encoded separately so it's easy to read but hard to fake. You can actually paste a JWT into a decoder online and see the header and payload in plain text — only the signature is secret.
Why JWTs Are Everywhere in Modern Apps
Before JWTs, websites used session IDs — a random number stored on the website's server. The problem? That number only works if the server that created it is the same one answering your request. This makes it hard to scale. If your website grows and you add more servers, a user might get logged out simply because their request landed on a different server than the one that created their session.
JWTs solve this because the data is inside the token itself. Any server that knows the secret can read and verify it — no need to call back to a central database. This makes JWTs perfect for:
- Microservices — many small services that all need to know who a user is
- Single sign-on — logging into one app and being automatically trusted by another
- API authentication — proving to a server API that a request is legitimate
💡 Key Insight
The JWT signature doesn't encrypt your data — it just proves nobody tampered with it. Anyone can still read the header and payload by Base64-decoding them. That's why you should never put secrets like passwords inside a JWT payload. The signature only proves the token wasn't modified; it doesn't hide the contents.
The JWT Login Flow Step by Step
Here's what happens when you log into a site that uses JWTs:
After login, every time your browser asks the server for something (like your profile data or a protected page), it attaches the JWT token in the Authorization header like this:
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
The server sees the token, checks the signature using its secret key, reads your user info from the payload, and decides whether to fulfill the request. If someone tries to change the payload to fake a different user ID, the signature no longer matches — and the server rejects it.
A JWT in Plain Code
Here's what a real JWT looks like when broken apart. Imagine a server issues this token after login:
// Part 1 — Header (Base64 encoded) eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 // Part 2 — Payload (Base64 encoded, readable) eyJ1c2VySWQiOiIxMjM0IiwibmFtZSI6IkFuZHJldyJ9 // Part 3 — Signature (server's secret proves authenticity) SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Decoded, the payload says: {"userId":"1234","name":"Andrew"}
Here's how you read and verify a JWT in JavaScript:
// The token that came from the server const token = "eyJhbGciOiJIUzI1NiJ9..."; // Read the payload without needing the secret const payload = jwt_decode(token); console.log(payload.userId); // "1234" console.log(payload.name); // "Andrew" // On the server, you verify with the secret key: const decoded = jwt.verify(token, SECRET_KEY);
Remember: anyone can decode a JWT to read the payload — but only the server can verify the signature is real.
Knowledge Check
Test what you learned about JWT tokens.