JWT Payload Design: 5 Mistakes That Leak Data or Break Authentication

You paste a token into a JWT decoder and there it is, plain as day: the user's email, their full name, their date of birth, and the internal role string your admin panel checks against. The token is signed, so nobody can change the values — but anyone holding the token can read every one of them, because a JWT's middle section is just Base64, not encryption. That's the gap most token leaks come from: teams treat the payload like a sealed envelope when it's actually a postcard. Here's how to design a payload that doesn't turn a leaked token into a leaked database.

The Postcard, Not the Envelope

The payload is Base64-encoded JSON. A Base64 converter can decode it in one step, and so can the decoder you'd paste it into — which is exactly why you should assume anyone with the token can read the payload. The rule of thumb: put nothing in the payload that you wouldn't write on the outside of an envelope. User ID, session identifier, role if your backend enforces it anyway — fine. Email, address, birth date, credit card last four — that's data that should only live on your server, and its only job in the token is to make a leak worse.

The Claims You Should Always Include

Beyond the obvious exp (expiration), a defensible payload carries four more registered claims. iss names the issuer, so a token minted by your login server is rejected by your API if it claims a different origin. aud names the intended audience — without it, a token meant for the mobile API silently works on the admin API if both share a secret. iat records when it was issued, which your hash-based revocation checks can lean on. And jti is a unique token ID, the single most underrated claim: it gives you a way to revoke a specific token or detect a replayed one. Four short strings, and a token that's hard to misuse even when it leaks.

The Design Review You Run

The counter-intuitive part: the payload is the cheapest place to fix a security problem, because you design it once and the format doesn't change the signing. Before you ship a token format, decode your own token and read it like an attacker would — we covered what to look for in our guide to what's actually inside a JWT. If any field makes you wince when you read it back, that's the field to move to the server. The signature proves the payload wasn't edited; it does nothing to keep it private. Design the postcard to survive being read, and a leaked token stops being an incident.