JWT Decoder

The header and payload sections of a JWT are only Base64URL-encoded — they are not encrypted. Anyone who holds the token can decode and read them. The secret key is only needed to verify the signature, which proves the token was issued by a trusted party and has not been altered. This is why you should never put sensitive data (passwords, full SSNs) in a JWT payload without additional encryption (JWE).

HS256 (HMAC-SHA256) uses a shared secret key — both the issuer and verifier share the same secret. This is simple but means anyone who can verify can also issue tokens. RS256 (RSA-SHA256) uses asymmetric keys — the issuer signs with a private key, and verifiers use the public key. The public key can be shared openly without compromising security. RS256 is preferred for distributed systems where multiple services need to verify tokens.

Standard registered claims (RFC 7519): iss (issuer), sub (subject — usually a user ID), aud (audience — intended recipient), exp (expiration time as Unix timestamp), nbf (not before — earliest valid time), iat (issued at timestamp), jti (JWT ID — unique identifier for the token). All are optional but recommended. Custom claims can be added alongside these standard ones.

HttpOnly cookies are generally recommended for storing JWTs in web apps — they cannot be read by JavaScript, which prevents XSS attacks from stealing the token. localStorage is convenient but accessible to any JavaScript on the page, making it vulnerable to XSS. If using localStorage, ensure robust XSS prevention and consider the sensitivity of the token. sessionStorage is similar to localStorage but cleared when the tab closes. For SPAs with strong XSS defenses, either approach can be reasonable with proper safeguards.

JWTs are stateless — once issued, they are valid until expiry unless you track them server-side. Common invalidation strategies: maintain a token blocklist/denylist (store revoked JTIs in Redis and check on each request), use short expiry times (15 min) with refresh tokens, rotate the signing secret (invalidates all existing tokens — use as a last resort), or use a version/generation field in the user record (increment on logout, compare in token claims). The blocklist approach is most practical for selective revocation.

A refresh token is a long-lived credential (days to weeks) stored securely (HttpOnly cookie or secure storage) used to obtain new short-lived access tokens (JWTs, 15 min – 1 hour) without re-authentication. When the access token expires, the client sends the refresh token to a token endpoint to get a new access token. Refresh tokens can be revoked and rotated for added security. This pattern limits the window of exposure if an access token is compromised.

The "none" algorithm attack exploits JWT libraries that accept "alg": "none" in the header, meaning no signature is required. An attacker modifies the payload (e.g., elevates privileges), sets "alg": "none" in the header, removes the signature, and sends the tampered token. A vulnerable library accepts it as valid. Mitigation: always explicitly specify and whitelist the expected algorithm(s) server-side — never allow "none" in production, and prefer libraries that enforce algorithm restrictions by default.

Yes — JSON Web Encryption (JWE, RFC 7516) provides encrypted JWTs. A JWE has five sections (header, encrypted key, IV, ciphertext, tag) and the payload is encrypted and unreadable without the private key. Signed-only JWTs (JWS) are the most common; they prove authenticity but not confidentiality. Use JWE when the payload contains sensitive data that must not be readable by the token holder or intermediaries. In practice, most applications use signed JWTs (JWS) and avoid putting sensitive data in the payload.

Common mistakes: not validating the exp claim (accepting expired tokens), not validating the aud claim (accepting tokens intended for other services), allowing alg: none, using weak or hardcoded secrets for HS256, storing full tokens in localStorage without XSS protection, not rotating refresh tokens after use (making them reusable after theft), putting sensitive personal data in the payload without encryption, and not verifying the signing algorithm matches what your app expects.