JWT Verifier

Decoding only base64url-decodes the header and payload so you can read them, and it always succeeds. Verifying recomputes the signature with your secret and compares it to the token, which proves the token was issued by someone who holds that secret and was not tampered with. This tool does both, but only a passing signature check means the token can be trusted.

The HMAC family: HS256, HS384 and HS512. These sign and verify with a single shared secret. Asymmetric algorithms such as RS256, ES256 and PS256 use a public key instead of a secret, so they are reported as unsupported here. The none algorithm is always treated as unverifiable.

No. The signature is recomputed locally in your browser with the Web Crypto API, so your token and secret never leave your machine. Even so, avoid pasting a real production secret into any online tool. Use a test secret whenever you can.

The most common cause is a secret that does not match the one used to sign the token, including a stray space, the wrong encoding, or a base64-encoded key entered as plain text. A mismatched algorithm or a token that was edited after signing will also fail. The header and payload still decode so you can compare the details.

They come from the exp and nbf claims, which are seconds since 1970. If exp is in the past the token is expired, and if nbf is in the future the token is not yet valid. A token is only fully valid when the signature checks out and it is within that time window.

Yes. A token can have a correct signature but be expired or not yet valid. This tool reports the signature result separately from the time checks, and the overall verdict is valid only when the signature passes and the token is inside its exp and nbf window.