How to Fix JWT "Invalid Signature" Errors

A JWT "invalid signature" error means the verification step recomputed the token's signature from its header and payload, and the result didn't match the signature that came attached to the token. This is a deliberate, working security check — it exists specifically to catch tokens that have been tampered with, or that were signed with a different secret than the one being used to verify them.

The single most common real-world cause isn't tampering at all — it's a secret mismatch between the service that issued the token and the service verifying it. This happens constantly in multi-environment setups: a token signed with your production JWT secret gets sent to a staging server verifying against a different staging secret, or a secret was rotated on one server but not the other, or the secret was pulled from a different environment variable than expected due to a typo in the variable name.

Whitespace is a surprisingly common culprit too. If the secret is loaded from an environment variable or a config file and picks up a trailing newline or extra space on one server but not the other, the two "secrets" are technically different strings even though they look identical when printed, and every signature verification will fail.

Algorithm mismatches cause the same symptom. If a token is signed with HS256 but the verifying code expects RS256 (or vice versa), verification fails in a way that often surfaces as an invalid signature error rather than a clearer algorithm-mismatch message, depending on the library. This is especially common when switching between symmetric secret-based signing and asymmetric public/private key signing partway through a project.

To debug this systematically, first decode the token (without verifying) to inspect its header and confirm which algorithm it claims to use — you can do this safely since decoding doesn't require the secret, only verifying does. Our JWT Decoder shows you the header and payload of any token instantly, which lets you confirm the algorithm and check the payload's claims without needing any code.

Once you know the algorithm, check that the exact same secret (byte for byte, no extra whitespace) is configured on both the signing and verifying services, pulled from the same source. If you're using asymmetric signing, confirm the verifying service has the correct public key that actually corresponds to the private key used for signing — a mismatched key pair produces this exact error too.

If the secret and algorithm both check out and you're still seeing failures, check whether the token was modified in transit — some proxies, browser extensions, or even copy-pasting into certain tools can alter whitespace or line breaks in a long token string, which is enough to break the signature even though the content looks unchanged to a human reading it.