JWT Decoder

Anatomy of a JWT

A JSON Web Token (RFC 7519) is a string with three dot-separated parts: header.payload.signature. Each part is encoded in URL-safe Base64 without padding. Header and payload are regular JSON; the signature is the result of running the declared algorithm over the concatenation of the first two.

The header typically has two fields: alg (signing algorithm, e.g. HS256, RS256, ES256) and typ (always JWT). The payload carries the claims — the data the server is trusting to the client.

Standard claims

The payload can contain anything, but seven registered claims have universal meaning:

• iss (issuer): who issued the token.
• sub (subject): who the token is about (typically the user ID).
• aud (audience): who the token is for.
• exp (expiration): Unix timestamp of expiration.
• nbf (not before): timestamp before which the token is invalid.
• iat (issued at): creation timestamp.
• jti (JWT ID): unique token identifier, useful for revocation.

Signing algorithms

1. HS256, HS384, HS512: HMAC with SHA-2. Symmetric: same secret signs and verifies. Simple for internal services.
2. RS256, RS384, RS512: RSA with SHA-2. Asymmetric: private key signs, public key verifies. Standard for OAuth/OIDC.
3. ES256, ES384, ES512: ECDSA with SHA-2. Like RSA but with elliptic curves: shorter signatures, better performance.
4. EdDSA (Ed25519): the most modern. 64-byte signatures, very fast, no dangerous parameters.
5. none: unsigned. Dangerous: never accept tokens with alg: none in production.

When to use JWT (and when not)

JWT shines when you need stateless authentication, rich claims, and clients or intermediate proxies that can read information without hitting your database again. Prototypical cases: federated APIs, OAuth, OIDC, integrations with third parties.

JWT is less great for plain browser sessions. A session cookie backed by a row in your database is simpler, more secure (instant revocation) and avoids JWT size issues. If your only need is "logged in or not", session cookies win.

Common vulnerabilities

• Algorithm confusion. A library that trusts the token's header can be tricked with alg: none or alg: HS256 against a public key. Always validate the algorithm in your code.
• No signature verification. Decoding is not verification. Some code only decodes and reads claims without checking the signature.
• No expiration. Tokens without exp are valid forever. Use short expirations and refresh tokens.
• Sensitive data in the payload. The payload is signed, not encrypted. Don't put passwords, keys or private data in it.
• No key rotation. If your HS256 secret leaks, you can sign tokens forever. Rotate periodically.

How JWT verification works in production

The correct server-side process:

1. Read the algorithm from the header but don't trust it: validate it against an allowed whitelist.
2. Verify the signature with the corresponding key.
3. Check exp, nbf, iss, aud.
4. Verify revocation if you keep a blacklist (jti).
5. Accept and read the claims.

This decoder only does the first step. For the rest, you need a library like jsonwebtoken (Node), PyJWT (Python) or jjwt (Java).