Is the payload of a JWT encrypted, and what should you not put in it?
SHORT ANSWER
No. The payload is only base64url encoded, so anyone holding the token can read it. Keep it small and non-sensitive: user id, role, expiry. Never put passwords, card details or personal secrets in it.
Explain it simply
A signed JWT is like a postcard with a tamper-proof seal. The postman cannot change the message without breaking the seal, but he can certainly read it. Signing gives integrity, not secrecy.
You can try it: paste any JWT into a debugger site, or decode it in a few lines.
Example
js
const token =
"eyJhbGciOiJIUzI1NiJ9." +
"eyJzdWIiOiI0MiIsInJvbGUiOiJzdHVkZW50In0." +
"signature-goes-here";
const payload = token.split(".")[1];
const json = Buffer.from(payload, "base64url").toString("utf8");
console.log(json); // {"sub":"42","role":"student"}No secret was needed to read that.
What belongs in a payload:
- User id (
sub), role, expiry (exp), issuer.
What does not:
- Passwords, OTPs, Aadhaar or card numbers, full addresses.
- Data that changes often, since the token carries the old copy until it expires.
Practical consequences:
- Tokens end up in browser storage and logs, so treat them like passwords: use HTTPS and short expiry.
- If you truly need an encrypted token, there is a standard for that called JWE, but most apps simply keep secrets on the server and put an id in the token.
What to say in the interview
"JWT payloads are encoded, not encrypted. The signature protects against tampering, so I put only non-sensitive claims like id, role and expiry, and send tokens over HTTPS."
Common mistakes
- Putting the user's email and phone in the payload without thinking about who can read it.
- Believing that a signed token hides its content.