JWT Explained: How to Read and Validate JSON Web Tokens

What Is a JWT?

A JSON Web Token (JWT) is a compact, self-contained way to transmit information between parties as a signed JSON object. The information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret key (HMAC) or a public/private key pair (RSA, ECDSA).

JWTs are widely used for authentication (knowing who the user is) and authorization (knowing what the user can do) in modern web applications and APIs.

The Three-Part Structure

A JWT consists of three Base64URL-encoded parts separated by dots:

xxxxx.yyyyy.zzzzz
header.payload.signature

Part 1: Header

{
  "alg": "HS256",
  "typ": "JWT"
}

The header declares the token type and the signing algorithm. Common algorithms:

• HS256 — HMAC with SHA-256 (symmetric — same secret for signing and verification)
• RS256 — RSA with SHA-256 (asymmetric — private key signs, public key verifies)
• ES256 — ECDSA with P-256 (asymmetric — smaller keys than RSA)

Part 2: Payload (Claims)

{
  "sub": "user_12345",
  "email": "user@example.com",
  "role": "admin",
  "iat": 1716000000,
  "exp": 1716086400
}

Claims are statements about an entity (user) and additional metadata.

Registered Claims (RFC 7519):

Custom Claims: You can add any claims you need (role, email, plan, etc.). Keep payload small — it's included in every request.

Part 3: Signature

HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret_key
)

The signature ensures the token hasn't been tampered with. For HMAC-signed tokens, only parties with the secret can create valid signatures. For RSA-signed tokens, anyone with the public key can verify signatures, but only the private key holder can create them.

How JWT Authentication Works

1. User logs in with credentials.
2. Server validates credentials, creates a JWT with user claims, signs it with secret key.
3. Server returns the JWT to the client.
4. Client stores the JWT (typically in memory or localStorage) and includes it in the Authorization header of subsequent requests: Authorization: Bearer <token>.
5. Server receives request, verifies JWT signature, checks exp, reads claims.
6. Server processes the request based on the claims.

No session state is required on the server — the JWT itself carries all necessary information.

Security Pitfalls and How to Avoid Them

1. Algorithm Confusion Attack

Some JWT libraries accept "alg: none" (no signature), allowing attackers to forge tokens. Always specify and validate the expected algorithm server-side.

2. Trusting the Payload Without Verification

The payload is Base64-encoded — not encrypted. Anyone can decode it. Never trust payload data without verifying the signature first.

3. Weak Secrets

HMAC secrets that are too short or predictable can be cracked. Use at least 256 bits of random data for HS256 secrets.

4. Not Checking Expiry

Always validate the exp claim. A valid signature on an expired token should still be rejected.

5. Storing Sensitive Data in Payload

Since the payload is not encrypted, never store passwords, credit card numbers, or other secrets in JWT claims.

6. No Token Revocation

JWTs are stateless — once issued, they're valid until exp. To revoke tokens before expiry, maintain a blocklist (by jti) or use short-lived tokens (15 minutes) with refresh tokens.

JWT vs Session Tokens

Reading a JWT with This Tool

Paste any JWT into the parser to instantly see:

• Decoded header and payload formatted as JSON
• Expiry status (expired / valid / time remaining)
• Signing algorithm
• All claims with human-readable timestamps

All processing happens in your browser — your token is never sent to any server.

→ Try the JWT Parser