What Is a JWT? JSON Web Tokens Explained

Q: Should I store JWTs in localStorage or cookies?

Both have trade-offs. localStorage: Accessible to JavaScript, so vulnerable to XSS attacks — a malicious script can steal the token. HttpOnly cookies: Not accessible to JavaScript, so XSS can't steal them — but vulnerable to CSRF attacks (mitigated with SameSite=Strict or CSRF tokens). The current consensus for sensitive tokens is HttpOnly, Secure, SameSite=Strict cookies. Avoid localStorage for authentication tokens in security-sensitive applications.

A JWT (JSON Web Token) is a compact, self-contained token for securely transmitting information between parties. Learn what JWTs are made of, how they work, and when to use them.

JWT Explained Simply

A JWT is a string with three Base64url-encoded sections separated by dots: header.payload.signature. The header describes the token type and algorithm. The payload contains claims (data). The signature verifies the token hasn't been tampered with.

Self-contained: All the information needed to verify the token is inside it — no database lookup required
Signed, not encrypted: The payload is readable by anyone — only the signature proves authenticity
Compact: Small enough to include in HTTP headers, URLs, and cookies
Stateless: The server doesn't need to store session state — the token carries it

Decode a JWT →

The Three Parts of a JWT

Header — Base64url-encoded JSON describing the token type and signing algorithm:
{"alg": "HS256", "typ": "JWT"}
Common algorithms: HS256 (HMAC-SHA256, shared secret), RS256 (RSA, public/private key pair), ES256 (ECDSA)
Payload — Base64url-encoded JSON containing claims (key-value pairs about the user or session):
{"sub": "user_123", "email": "alice@example.com", "exp": 1700000000, "iat": 1699996400}
Signature — Computed as HMAC-SHA256(base64url(header) + "." + base64url(payload), secret) for HS256, or an RSA/ECDSA signature for asymmetric algorithms. Verifying the signature proves the token was issued by a trusted party and hasn't been modified

Standard JWT Claims

sub (Subject): The entity the token is about — typically a user ID
iss (Issuer): Who issued the token — e.g., "https://auth.example.com"
aud (Audience): Who the token is intended for — the API or service that should accept it
exp (Expiration): Unix timestamp after which the token is invalid — always validate this
iat (Issued At): Unix timestamp when the token was created
jti (JWT ID): Unique identifier for the token — used to prevent replay attacks by blacklisting used tokens

Frequently Asked Questions

Can anyone read the contents of a JWT?

Yes — the header and payload are Base64url-encoded, not encrypted. Anyone who has the token can decode and read the claims. Never store sensitive data (passwords, credit card numbers, PII beyond what's necessary) in a JWT payload. The signature prevents modification but not reading. If you need to hide the payload contents, use a JWE (JSON Web Encryption) instead of a plain JWT.

What's the difference between HS256 and RS256?

HS256 uses a single shared secret for both signing and verification — both the issuer and verifier must know the same secret key. RS256 uses an asymmetric key pair: the issuer signs with a private key, and verifiers check the signature using the public key. RS256 is better for distributed systems where multiple services need to verify tokens but shouldn't have signing capability — they only get the public key. HS256 is simpler for single-server setups.

Should I store JWTs in localStorage or cookies?

Both have trade-offs. localStorage: Accessible to JavaScript, so vulnerable to XSS attacks — a malicious script can steal the token. HttpOnly cookies: Not accessible to JavaScript, so XSS can't steal them — but vulnerable to CSRF attacks (mitigated with SameSite=Strict or CSRF tokens). The current consensus for sensitive tokens is HttpOnly, Secure, SameSite=Strict cookies. Avoid localStorage for authentication tokens in security-sensitive applications.