What a JWT actually contains
A JSON Web Token usually has three dot-separated parts: a header, a payload, and a signature. The header describes the token type and algorithm. The payload contains claims such assub, iss, aud, and exp, all defined in RFC 7519. The signature helps a verifier detect tampering.
In the common signed format, the first two parts are Base64URL-encoded JSON. Encoding makes the token portable; it does not hide the contents. Do not put secrets in a normal JWT payload, and do not treat a decoded payload as trustworthy until the signature and claims have been checked.
Why online decoding can leak a token
A server-side decoder must receive the token to decode it. That creates more copies and more places to investigate: request logs, reverse proxies, analytics, error reports, browser history, and backups. HTTPS protects the connection between you and the service, but it does not prevent the service from seeing or retaining the token after it arrives.
A token may be short-lived, but that is not a reason to paste it into an unknown service. It can still expose personal data during its lifetime, and a stolen bearer token may be usable until it expires or is revoked. Use a redacted sample or a local decoder while debugging.
It is also worth remembering that a website's own backend is rarely the only place a pasted token can end up. Crash reporters and error-monitoring tools (Sentry-style services are a common example), third-party analytics scripts, and CDN or proxy logs sitting in front of the decoder can all capture request bodies without the site operator doing anything malicious — they are just logging traffic the way these tools normally do. That is a lot of places for a live session token to be sitting in plaintext, and none of them are places you can audit from the outside.
Decode and verify are different jobs
These terms are used interchangeably in tutorials, but they are fundamentally different operations with different security implications.
| Feature | Decode | Verify | ★ RecommendedValidate |
|---|---|---|---|
| Reads header + payload JSON | |||
| Cryptographically checks signature | |||
| Checks exp / nbf / iss / aud claims | |||
| Can be done without the signing key | |||
| Required before granting access | |||
| Safe to do in a browser tool |
A browser tool can help with inspection and controlled testing, but it is not a replacement for server-side authorization checks. Never grant access because a token merely looks valid in a UI.
A safer JWT debugging workflow
Use a locally running or browser-local decoder for real tokens
The network tab should show zero outbound requests when you paste a token.
Redact tokens before posting screenshots, tickets, or Slack messages
Live session tokens in screenshots have a habit of ending up in search indexes and archive tools.
Check algorithm, issuer, audience, and expiry against your app config
Algorithm confusion attacks (RS256 vs HS256) are still a real exploit class.
Revoke or rotate a token if you pasted it into an untrusted service
Short expiry does not eliminate risk — a stolen bearer token is usable until it expires.
Never store sensitive PII (emails, phone numbers, financial data) in JWT payloads
JWT payloads are encoded, not encrypted. Anyone with the token sees the payload.
Keep signature verification in the application that owns the private key
Never delegate authorization decisions to client-side code.
What should never end up in a JWT payload
Teams get burned by this in a pretty consistent way. Someone needs to pass a bit of extra context through the auth layer, so they add a field to the payload. Six months later that field is a password reset token, a raw email address tied to a support ticket, or an internal user ID that maps directly to a database row. None of that is encrypted. Anyone who has the token, or anyone who runs it through any decoder, sees it in plain JSON.
A reasonable rule: if you would not put it in a URL query parameter, do not put it in a JWT payload. Roles and permission scopes are fine. A stable, non-guessable user ID is usually fine. Full names, emails, phone numbers, and anything from a compliance-sensitive field (health data, financial data, government IDs) should not be there. If the application needs that data after verifying the token, look it up server-side using the subject claim instead of carrying it around in the token itself.
Where tokens actually end up leaking
This is not a hypothetical concern. A number of developers writing about this on Hacker News have described the same pattern: a token pasted into jwt.io or a similar tool during debugging, then found weeks later sitting in a browser extension's telemetry log, a support ticket attachment, or a shared team Slack channel because someone screenshotted the decoded output without thinking about what was in it. None of those are dramatic hacks. They are ordinary workflow habits that happen to leave a live credential somewhere it should not be.
The fix is not complicated. Treat a JWT the way you would treat a password: never paste it somewhere you have not personally verified is safe, and prefer tools where you can watch, in your own browser's network tab, that nothing was sent anywhere.
JWTs themselves are defined in RFC 7519, and the signature mechanics that make a token verifiable (not encrypted — verifiable) come from RFC 7515. OWASP also has a good rundown of common JWT attack patterns worth reading if you are building anything that issues or verifies tokens. If you just need to inspect one right now without pasting it into a random website, our JWT decoder runs the whole thing locally in your browser.