JSON Web Tokens (JWTs) are the backbone of modern authentication. They carry user identities, permissions, and session data across every major web application. But JWTs also carry sensitive information that most developers casually paste into online decoders without a second thought. This guide will show you why that is dangerous and how to inspect JWTs safely.
Understanding JWT Structure
A JWT consists of three Base64URL-encoded parts separated by dots: the header, the payload, and the signature. The header specifies the token type and signing algorithm. The payload contains claims — statements about an entity (typically the user) and additional data. The signature is used to verify the token has not been tampered with.
Here is what makes JWTs sensitive: the payload is not encrypted. It is merely encoded. Anyone with access to the token can decode it and read all the claims. This means a JWT may contain user IDs, email addresses, roles, permissions, expiration times, and even custom application-specific data that you do not want exposed.
Common JWT Vulnerabilities
- Algorithm confusion attacks: If your application accepts tokens signed with different algorithms, an attacker could potentially forge tokens by switching from RS256 to HS256.
- "None" algorithm: Some JWT implementations accept tokens with the algorithm set to "none," effectively bypassing signature verification entirely.
- Weak secrets: Tokens signed with HS256 using weak secrets can be cracked using brute force or dictionary attacks.
- Token leakage: Pasting production JWTs into online decoders leaks them to third-party servers. If those tokens are long-lived, attackers gain extended access.
- Missing validation: Failing to validate the "exp" (expiration), "iss" (issuer), and "aud" (audience) claims can lead to token reuse and impersonation attacks.
Why Online JWT Decoders Are Risky
When you paste a JWT into an online decoder, you are sending it to a server you do not control. Even if the website appears legitimate and claims not to log data, you have no way to verify this. The server could log your token, store it indefinitely, or pass it to third-party analytics services.
If your JWT contains a session token or an API key, you have just given a stranger access to your account or infrastructure. If the token is long-lived (and many are), the exposure window could be days or weeks. This is not a theoretical risk — security researchers regularly find exposed tokens in server logs and data dumps.
Safe JWT Inspection
The safe approach is to decode JWTs locally, in your browser, without sending them to any server. A client-side JWT decoder reads the token using JavaScript's built-in Base64 decoding functions. The header and payload are decoded and displayed instantly, entirely within your browser's memory. No network request. No server log. No data exposure.
Formatho's JWT Decoder works exactly this way. Paste your token, inspect the claims, verify the structure — all without a single byte leaving your machine. This is how token inspection should work.