Common JWT Errors and How to Fix Them

JSON Web Tokens (JWTs) are used everywhere for authentication and authorization. When something goes wrong, the error messages can be cryptic. Here are the most common JWT errors you’ll run into and how to fix them—plus how to use a free JWT decoder to debug quickly.

1. Invalid signature / Signature verification failed

This usually means the token was signed with a different key than the one you’re using to verify, or the token was tampered with.

• Wrong secret or key: For HS256, the verifier must use the same secret as the signer. For RS256, use the correct public key that matches the signer’s private key.
• Key format: Ensure the key is in the expected format (e.g. PEM for RS256) and that you’re not using a public key where a secret is required (or vice versa).
• Key ID (kid): If the JWT header has a kid, your server must resolve it to the right key. Using the wrong key leads to invalid signature.

Fix: Confirm the signing key/secret and key format on both sides. Use a JWT decoder to inspect the header (e.g. alg, kid) and payload, then verify with the correct key locally or in your app.

2. Token expired (exp claim)

JWTs often include an exp (expiration) claim. If the current time is past exp, libraries will reject the token.

• Check the exp value in the payload (it’s a Unix timestamp in seconds).
• Ensure server and client clocks are roughly in sync (e.g. NTP).
• If you’re testing, either use a token with a future exp or temporarily skip expiration checks in non-production only.

Fix: Decode the token and look at exp. If it’s in the past, the user needs a new token (e.g. refresh flow). For local debugging, decode with our JWT tool to see the exact expiration time.

3. Invalid token format / Not enough segments

A valid JWT has three base64url parts separated by dots: header.payload.signature. If you see “not enough segments” or “invalid format”:

• The string might be truncated (e.g. copied partially from a log or header).
• Extra spaces, newlines, or quote characters might have been included.
• The token might be double-encoded or wrapped in JSON (e.g. {"token":"eyJ..."}); use the inner eyJ... value only.

Fix: Paste the raw token (just the three dot-separated segments) into a decoder. Strip any prefix like Bearer , quotes, or whitespace before decoding.

4. Algorithm mismatch (e.g. alg: "none" or wrong alg)

The alg in the header must match what your server expects. Two common problems:

• alg: "none": Some libraries used to allow “none” and skip verification. Treat this as insecure and reject such tokens. Ensure your library does not accept alg: "none".
• Wrong algorithm: Token might be signed with HS256 but you’re verifying with RS256 (or the other way around). The key type and algorithm must be consistent.

Fix: Decode the token and read the alg in the header. Configure your verifier to use that algorithm and the matching key type (symmetric for HS256, public key for RS256).

5. Invalid Base64 or malformed payload

Header and payload are base64url-encoded JSON. If decoding fails:

• Characters might not be valid base64url (only A–Z a–z 0-9 - _).
• Padding might be wrong (base64url often omits =; some decoders are strict).
• The decoded JSON might be invalid (missing quotes, trailing commas, etc.).

Fix: Re-copy the token from the source (browser, API response) and avoid manual edits. Use a decoder that accepts base64url; if it still fails, the token may be corrupted or not actually a JWT.

Quick debugging with a JWT decoder

When you’re not sure what’s wrong, paste the token into a decoder to see the raw header and payload without writing code. You can:

• Check alg, kid, and other header fields.
• Read exp, iat, sub, and custom claims.
• Verify signatures (e.g. RS256) if the tool supports it.

Once you know the exact algorithm, expiration, and key ID from the decoded token, you can fix configuration on your auth server or client and get past these common JWT errors quickly.