JWT Tokens Explained: Structure, Claims, and Debugging

A JWT looks like `eyJhbGci...` with two dots separating three Base64URL-encoded segments: header (algorithm and type), payload (claims), and signature (proof the token was not tampered with). Decoding the first two segments is trivial—anyone can read them. Security comes from the signature verified with a secret or public key.

• Header: `{ "alg": "HS256", "typ": "JWT" }`
• Payload: claims like `sub`, `exp`, `iat`, and custom fields
• Signature: HMAC or RSA over `header.payload`

Expired tokens (`exp` in the past) should be rejected before your handler runs. Clock skew between servers causes edge-case failures—allow a small leeway (e.g. 30 seconds) in verification libraries.

HMAC algorithms (HS256, HS384, HS512) use a shared secret—simple for monoliths and internal services. RSA/ECDSA (RS256, ES256) use a private key to sign and a public key to verify—better when many services verify but only one issues tokens.

1. 1

   Decode without verifying

   Confirm structure and read exp, aud, and custom claims.

2. 2

   Check expiration

   Convert exp to human time; refresh tokens if expired.

3. 3

   Verify signature

   Use the correct secret or public key and algorithm from the header.

4. 4

   Validate audience and issuer

   Mismatch here causes valid-looking tokens to fail policy checks.

The JWT Tool on XSular Tools decodes header and payload, highlights expiration, verifies HMAC signatures, and generates test tokens—all client-side. Your secrets never leave the tab, which matters when debugging staging environments from a laptop.