JWT Is Not Encrypted, Just Base64
Who can see what's inside the JWT token sent with every request of your app? Answer: everyone. Here's what tokens actually store, why signature verification is enough, and 4 things you should never put in the payload.
This is the token sent with every request in your app. Who do you think can read what's written inside it? The answer is simple: everyone.
Three Parts
Every JWT is split into three parts by dots: header.payload.signature. The first two aren't encrypted, they're just Base64 encoded. Base64 isn't encryption, it's just an encoding format—it can be decoded anytime.
const [header, payload] = token.split(".");
console.log(JSON.parse(atob(payload)));
// { sub: "user_123", email: "...", role: "admin", exp: 1735689600 }When you paste this into your browser console, your email address, user ID, role, and expiration date pop up right in front of you. That's why you should never put passwords, national ID numbers, or card details into a JWT payload.
Can I just edit it and become an admin?
You could edit the payload and write role: "admin"—Base64 is two-way encoding, after all. But the server recalculates the signature using a secret key only it knows. The signature won't match your forged payload, and the server rejects the token: 401. You can read the payload, but you can't tamper with it unnoticed.
Four Rules
Important: Working with JWTs
- Don't put sensitive data in the payload—treat it as public.
- Always re-verify authorization (
role,permissions) on the server; don't blindly trust the token. - Keep expiration times short, and use refresh tokens for long sessions.
- Read the signing secret (
secret) from.env, not hardcoded in code, and never log it anywhere.
Wrapping Up
JWT's job isn't confidentiality, it's integrity: it guarantees the content hasn't been tampered with, not that the content is hidden. If you have data that really needs to stay secret, use JWE (encrypted JWT) or traditional server-side sessions.
