What Decoding a JWT Actually Does

A JWT token looks like a string of random characters, but it is actually three Base64URL-encoded JSON objects joined by dots. Decoding simply reverses the Base64URL encoding — no key or cryptographic operation required for reading the contents.

This is a frequently misunderstood point: you do not need the signing secret to read a JWT's contents. The payload is publicly readable by anyone with the token string. What the signature protects is the integrity of the token — proving it was issued by a trusted party and has not been modified.

See our complete guide to what a JWT token is for a full explanation of the structure.

How to Find Your JWT Token

Depending on how the application stores the token, you can find it in several places:

Browser Developer Tools

  1. Open Developer Tools (F12 on Windows/Linux, Cmd+Option+I on Mac)
  2. Go to the Application tab
  3. Check under Cookies for your domain — look for a cookie named token, auth_token, jwt, or similar
  4. Check under Local Storage and Session Storage as well

Network Tab

If the token is sent as a request header:

  1. Open Developer Tools → Network tab
  2. Make any authenticated request (e.g., load the dashboard)
  3. Click on the request and go to Request Headers
  4. Look for Authorization: Bearer eyJ...

Every JWT starts with eyJ because the header always begins with {" which Base64URL-encodes to eyJ.

Step-by-Step: Decoding a JWT Online

  1. Copy the full JWT token string (the entire eyJ...xxx.eyJ...yyy.zzz string)
  2. Open ToolMasta's JWT Decoder tool
  3. Paste the token into the input field
  4. The tool immediately displays three sections: Header, Payload, and Signature status
  5. All claims in the payload are shown with human-readable timestamps for exp, iat, and nbf

There is no button to click — decoding is instantaneous as you type or paste.

Reading and Understanding Claims

A decoded JWT payload typically looks like this:

{
  "sub": "user_id_12345",
  "email": "user@example.com",
  "role": "admin",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1718352000,
  "exp": 1718355600
}

Key claims to look for:

  • sub — the subject (user identifier). Confirm this is the user you expect.
  • iss — the issuer. Should match your authentication service URL.
  • aud — the audience. Should match the service this token is intended for.
  • exp — expiration. A Unix timestamp (seconds since epoch). Convert to a date to see when the token expires.
  • iat — issued at. Shows when the token was created.
  • role / permissions — custom claims added by your application.

Checking Token Expiry

The exp claim is a Unix timestamp. To convert manually: the number represents seconds since January 1, 1970 UTC. For example, 1718355600 converts to June 14, 2024 at 09:00 UTC.

ToolMasta's decoder converts exp, iat, and nbf timestamps to human-readable dates and shows whether the token is currently valid, expired, or not yet active.

Debugging tip: If users report intermittent authentication failures, check whether the exp time is set too short. Also verify that the server's system clock is synchronised (NTP) — clock skew between the issuer and verifier can cause tokens to appear expired before they actually are.

Verifying the Signature

Decoding reads the payload without verification. Verifying the signature proves the token was issued by a trusted party and has not been tampered with.

To verify an HS256 token, you need the shared secret. To verify an RS256 or ES256 token, you need the issuer's public key (often available at the issuer's JWKS endpoint: https://auth.example.com/.well-known/jwks.json).

ToolMasta's JWT decoder supports signature verification for HMAC-signed tokens when you supply the secret key. This is useful for development and debugging — never share production secrets.

Common Debugging Scenarios

401 Unauthorized: Token Expired

Check the exp claim. If it is in the past, the token has expired. The client needs to refresh the token or re-authenticate. If this is happening too quickly, consider extending the access token lifetime or improving the refresh flow.

403 Forbidden: Missing Permission

The token may be valid but missing a required role or permission claim. Decode the payload and check custom claims like role, scope, or permissions.

Invalid Audience

If aud claim does not match what the API expects, the request will be rejected. Confirm the token was issued for the correct audience.

Algorithm Mismatch

Check the alg field in the header. If your server expects RS256 but the token was signed with HS256, verification will fail. Ensure the issuer and verifier agree on the algorithm.

Security: Is It Safe to Paste a Token?

ToolMasta's JWT decoder processes tokens entirely in your browser using JavaScript. No data is transmitted to any server. You can verify this by opening your browser's network panel while using the tool — there are no outbound requests triggered by pasting a token.

However, as a general rule: avoid pasting production tokens (especially long-lived refresh tokens) into any online tool you do not fully trust. For development and short-lived access tokens, browser-based decoders like ToolMasta are entirely safe. For maximum caution with sensitive tokens, decode offline using a JWT library in your preferred language.

Try It Free — No Signup Required

Decode any JWT token instantly. All processing happens in your browser — your token never leaves your device.

Open JWT Decoder