JWT Decoder

The Three Parts of a JWT

A JSON Web Token consists of three Base64url-encoded sections separated by dots: header.payload.signature. The header specifies the token type and signing algorithm (alg: "HS256" for HMAC-SHA256, RS256 for RSA). The payload contains claims — statements about the user and metadata. The signature verifies the token was issued by a trusted party and hasn't been tampered with. The header and payload are merely encoded, not encrypted — anyone can decode and read them. Only the signature requires the secret key to verify.

Standard Claims

JWTs use registered claim names defined in RFC 7519. The most important: sub (subject — typically user ID), iss (issuer — who created the token), aud (audience — intended recipient), exp (expiry timestamp in Unix epoch), iat (issued at timestamp), and nbf (not before — token not valid until this time). Applications add custom claims for roles, permissions, and other user data. Verify exp, iss, and aud on every token to prevent expired, mis-issued, or cross-service token reuse attacks.

Signature Verification and the alg:none Attack

The signature is the critical security component. For HS256, the server signs and verifies using the same secret key (symmetric). For RS256, the issuer signs with a private key and verifiers use the corresponding public key (asymmetric — safer for multi-service architectures). A critical historical vulnerability is the alg: "none" attack: early libraries accepted tokens with no algorithm specified, treating them as valid without signature verification. Always explicitly specify which algorithms your library should accept and reject tokens specifying none. Never trust the algorithm specified in the token header — validate against your expected algorithm.

JWT vs Session Cookies

JWTs are stateless — the server doesn't store them; all necessary information is in the token. Session cookies store a session ID that references server-side session state. Stateless JWTs scale horizontally without shared session storage, making them popular for microservices. The tradeoff: JWTs cannot be revoked before expiry without adding a server-side blocklist (reintroducing state). For user logout or account suspension to take immediate effect, you need either short expiry times (minutes) or a token revocation mechanism. Session cookies allow immediate revocation by deleting the server-side session. For most web applications, short-lived JWTs (15 minutes) with refresh tokens provide a practical balance.