JWT Decoder

What Is a JSON Web Token (JWT)?

A JWT is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three Base64URL-encoded parts separated by dots: the header (algorithm and token type), the payload (claims and data), and the signature (verification that the token hasn’t been tampered with).

Standard JWT Claims

The JWT specification defines seven standard claims: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID). These are all optional but widely used for authentication and authorization workflows.

HS256 vs RS256

HS256 uses a shared secret key for both signing and verification — both the issuer and verifier need the same key. RS256 uses an asymmetric key pair: a private key for signing and a public key for verification. RS256 is more secure for distributed systems because you never need to share the private key.

JWT Security Best Practices

Never store sensitive data in JWTs — they are encoded, not encrypted. Always set reasonable expiration times (15 minutes for access tokens, days for refresh tokens). Validate all claims on the server, especially exp, iss, and aud. Use HTTPS to prevent token interception, and implement token refresh rotation to limit the damage of stolen tokens.

JWT Expiration and Clock Skew

Three time-based claims govern a JWT’s validity window. The exp (expiration) claim sets the timestamp after which the token must be rejected. The iat (issued at) claim records when the token was created, which is useful for auditing and detecting tokens that were issued unusually far in the past. The nbf (not before) claim specifies the earliest time the token is valid, allowing tokens to be issued ahead of time for scheduled access. Servers validating these claims typically allow a small clock skew — usually 30 to 60 seconds — to account for minor differences between server clocks in distributed systems. One often overlooked risk is long-lived tokens: a refresh token valid for 90 days gives an attacker a large window if the token is ever stolen, so pairing long expiration with token rotation and revocation lists is strongly recommended.

Common JWT Vulnerabilities and How to Avoid Them

The alg: none attack is one of the most well-known JWT vulnerabilities: a malicious actor crafts a token that sets the algorithm header to none, effectively removing the signature requirement. Any library that blindly trusts the algorithm value in the header will accept these unsigned tokens as valid. Always enforce a strict allowlist of accepted algorithms on your server and never derive the verification algorithm from the token itself. A subtler attack targets RS256 implementations: if a server accepts both HS256 and RS256, an attacker can take the RS256 public key (which is often publicly distributed), use it as an HS256 secret to sign a forged token, and trick a misconfigured server into accepting it. Finally, remember that JWTs are only Base64URL-encoded — not encrypted. Any claim in the payload is readable by anyone who holds the token, so fields like passwords, credit card numbers, or other secrets must never appear in a JWT without an additional encryption layer (JWE).

When investigating a JWT, the Base64 & Encoding Toolkit lets you manually decode individual token segments and experiment with encoding schemes. To verify HMAC signatures or check the integrity of API payloads outside of a full JWT flow, the Hash Generator provides SHA-256 and HMAC-SHA utilities that pair naturally with JWT inspection work.