JWT Explained: Structure, Claims, and How to Decode One

A JSON Web Token (JWT) is a compact, URL-safe token format used to securely transmit claims between parties. They are the backbone of modern stateless authentication: your server issues a JWT on login, and the client presents it with every subsequent request. Decode any JWT instantly with the JWT Decoder no library required.

JWT Structure: Three Base64-Encoded Parts

A JWT consists of three period-separated segments:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header (first part) algorithm and token type. Typically {"alg":"HS256","typ":"JWT"}
• Payload (second part) the claims: who the token is for, when it expires, custom data
• Signature (third part) HMAC or RSA signature over header + payload to detect tampering

The header and payload are Base64URL encoded not encrypted. Anyone with the token can read them. Use the Base64 Encoder/Decoder to manually decode either segment if needed.

Standard JWT Claims

The JWT specification (RFC 7519) defines registered claims:

• iss (Issuer) who created the token
• sub (Subject) who the token is about (typically a user ID)
• aud (Audience) intended recipients
• exp (Expiration Time) Unix timestamp after which the token is invalid
• iat (Issued At) when the token was created
• jti (JWT ID) unique identifier to prevent replay attacks

How JWT Signature Verification Works

The signature prevents tampering. With HMAC (HS256): the server signs base64url(header) + "." + base64url(payload) using a secret key. Any modification to the payload invalidates the signature. With RSA (RS256): the server signs with a private key; anyone with the public key can verify this is the approach used by OAuth2 providers like Google and Auth0.

Critical: decoding is not verification. The JWT Decoder reads the payload without verifying the signature useful for debugging, but never accept decoded claims as trusted without server-side signature verification.

Common JWT Security Mistakes

• Accepting "none" algorithm some early libraries accepted tokens with "alg":"none" and no signature. Always explicitly whitelist algorithms.
• Storing JWTs in localStorage accessible to any JavaScript on the page, including XSS payloads. Use httpOnly cookies where possible.
• No expiry claim tokens without exp are valid forever. Always set a short expiry (15 minutes for access tokens) and use refresh tokens.

Frequently Asked Questions

Is JWT the same as OAuth?

No. OAuth 2.0 is an authorisation framework that defines flows for delegating access. JWT is a token format that OAuth (and OpenID Connect) commonly use to encode tokens. You can use JWTs without OAuth. See Auth0's JWT guide for a thorough breakdown of the relationship.

Should JWT data be encrypted?

Standard JWTs (JWS) are signed but not encrypted the payload is readable by anyone with the token. If your payload contains sensitive data, use JWE (JSON Web Encryption) instead. Most use cases only need JWS with short expiry and minimal claims in the payload.

How do I invalidate a JWT before it expires?

JWTs are stateless by design there is no central revocation list. Common approaches: maintain a server-side blocklist of jti values, use short-lived tokens (15 min) with refresh token rotation, or implement token families that invalidate on detection of reuse.