JWT Authentication: A Practical Guide for Developers

Quick Answer

Quick Answer: A JWT is three Base64URL-encoded parts—header, payload, and signature—joined by dots. Decode the payload with our JWT Decoder to inspect claims; always verify signatures on the server before trusting data.

JWT structure

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SIGNATURE
   HEADER              PAYLOAD           SIGNATURE

The header declares the algorithm (alg) and type (typ). The payload holds claims—statements about the user or token.

Common claims

If exp is in the past, the token is expired—our decoder highlights this.

Debugging invalid tokens

1. Paste the token into the JWT Decoder.
2. Confirm alg matches what your API expects.
3. Check clock skew—servers often allow 30–60s leeway on exp.
4. Remember: decoding ≠ verification. Anyone can read the payload; only the server with the secret/key can verify the signature.

Example payload

{
  "sub": "user_42",
  "name": "Alex",
  "iat": 1710000000,
  "exp": 1710003600
}

Security notes

• Never put secrets in the JWT payload—it is only encoded, not encrypted.
• Prefer short-lived access tokens + refresh flow for web apps.
• Rotate signing keys and invalidate refresh tokens on logout.

Try It Yourself

Decode a JWT now →

Frequently Asked Questions

Is JWT encrypted?

No. JWTs are signed (integrity) or encrypted only if you use JWE, which is less common than signed JWS.

Can I trust the payload without verifying the signature?

No. Treat unverified payloads as untrusted hints only.

HS256 vs RS256?

HS256 uses a shared secret—fine for monoliths. RS256 uses public/private keys—better when multiple services verify tokens.