JWT Decoder

What is a JSON Web Token (JWT)?

JWT (JSON Web Token) is an open standard defined in RFC 7519 for securely transmitting information between parties as a compact JSON object. Tokens are digitally signed using HMAC or RSA/ECDSA algorithms, ensuring data integrity. JWTs are widely used for authentication and authorization in APIs and web applications.

Unlike session-based authentication, JWT is stateless — the server does not need to store sessions. All user information is encoded in the token itself, making it easy to scale horizontally and work well with microservices architectures.

JWT Structure: 3 Parts

Every JWT consists of three parts separated by dots (.):

• Header (blue): Contains the signing algorithm (alg) and token type (typ).
• Payload (green): Contains the claims — the actual data such as user ID, role, and expiration time.
• Signature (red): A cryptographic signature created from the header + payload + secret key. Only the server holding the secret key can verify it.

Both the header and payload are Base64url encoded — not encrypted. Anyone who has the token can read its contents. Only the signature ensures the token has not been tampered with.

Registered Claims

RFC 7519 defines 7 registered claims. They are optional but strongly recommended:

Signing Algorithms: HS256 vs RS256

HS256 (HMAC + SHA-256): A symmetric algorithm — the same secret key is used to sign and verify. Simple, fast, and suitable for single-server applications or when both the signer and verifier are mutually trusted.

RS256 (RSA + SHA-256): An asymmetric algorithm — the private key signs, the public key verifies. More secure for distributed systems because only the auth server holds the private key; other services only need the public key to verify tokens. Common with OAuth 2.0 and OpenID Connect.

Common JWT Mistakes

• Storing JWT in localStorage: Vulnerable to XSS attacks. Use httpOnly cookies instead.
• Not checking exp: Always validate the expiration timestamp before trusting a token.
• Weak secret key: Use at least 256-bit random keys for HS256. Never use predictable strings like "secret" or "password".
• Sensitive data in payload: The payload is readable by anyone. Never store passwords, credit card numbers, or PII in JWT claims.
• No token revocation: JWTs are stateless, so you cannot "logout" by deleting a server-side session. Use a token blacklist or the refresh token pattern for revocation.

JWT in API Authentication

The typical JWT auth flow: (1) Client sends username/password to the auth endpoint. (2) Server verifies credentials, creates a JWT containing user ID and role, signed with a secret key. (3) Client receives the token and attaches it in the Authorization: Bearer <token> header for every request. (4) Server verifies the signature + checks exp → allows or denies the request.

A common pattern uses access tokens (short-lived, 15 minutes) paired with refresh tokens (long-lived, 7 days). When the access token expires, the client uses the refresh token to obtain a new access token without re-entering credentials.

JWT Security Best Practices

• Always use HTTPS to prevent token interception in transit.
• Set short expiration times for access tokens (15 minutes or less).
• Use the aud claim to restrict token usage to intended services.
• Implement token rotation and refresh token reuse detection.
• Use RS256 in distributed systems to avoid sharing secret keys.
• Validate all claims on the server side: iss, aud, exp, nbf.